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can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 



This Technical Specification (TS) has been produced by ETSI Technical Committee Digital Enhanced Cordless 
Telecommunications (DECT). 

The present document is based on EN 300 175, parts 1 [1] to 8 [8], EN 300 444 [9] and EN 301 649 [i.5]. General 
attachment requirements are based on EN 301 406 [11] (replacing TBR 006 [i.2]). Further details of the DECT system 
may be found in TR 101 178 [i.l]. 

The present document has been developed in accordance to the rules of documenting a profile specification as described 
in ISO/IEC 9646-6 [i.3]. 

The information in the present document is believed to be correct at the time of pubUcation. However, DECT 
standardization is a rapidly changing area, and it is possible that some of the information contained in the present 
document may become outdated or incomplete within relatively short time-scales. 

The present document is part 1 of a multi-part deliverable covering Machine to Machine Communications based on 
DECT Ultra Low Energy (ULE) as identified below: 

Part 1: "Home Automation Network (phase 1)". 

The present document defines the functionality for phase 1 of DECT Ultra Low Energy (ULE), Home Automation 
Network (HAN). Further phases with additional functionality will be defined in the future by other parts of this 
multi-part deliverable. 
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Scope 



The present document specifies the first set of functionahties of the ETSI radio technology named DECT Ultra Low 
Energy (ULE). DECT ULE provides bi-directional radio communication with medium range, data protection, and Ultra 
Low Power consumption between different types of Portable Devices and Radio Fixed Parts. 

DECT ULE has been created by the ETSI Technical Committee DECT, and is based on the DECT base standard 

EN 300 175, parts 1 [1] to 8 [8], and the DECT Packet Radio Service (DPRS), EN 301 649 [i.5]. However DECT ULE 

includes substantial differences with its parent technology in order to achieve Ultra Low Power consumption. 

The present document is part 1 of a multipart deliverable intended to cover the Machine to Machine communications 
based on DECT Ultra Low Energy (ULE). 

The set of features defined in the present document is named "Home Automation Network (HAN), phase 1", and is 
primarily targeted to provide a global M2M solution within domestic scenarios. However, this does not prevent the use 
of the present document in other scenarios. 

Further phases of the Home Automation Network (HAN) or further Machine to Machine applications based on DECT 
ULE will be defined in the future by other parts of this multi-part deliverable or by separate Technical Specifications. 

From the point of view of DECT standardization, the present document is an application profile (AP) based on the 
DECT base standard (EN 300 175, parts 1 [1] to 8 [8]). This application profile (AP) may reuse definitions and 
procedures defined in other DECT applications profiles when needed or convenient. This is the case, for instance, of the 
DECT Generic Access Profile (GAP), EN 300 444 [9] and the DECT Packet Radio Service (DPRS), EN 301 649 [i.5]. 

DECT Ultra Low Energy (ULE) Part 1 (the present document) provides the following basic functionalities: 

• MAC/PHY Layer 

Unlocked, ultra low duty cycle operation for battery powered Portable Part devices 

■ PP may enter in "deep sleep" state between activity cycles with near all circuits switched off (with 
loss of synchronization to the base) 

Provisions for Fast Locking so the Portable Part device can remain in long sleep cycles and regain the 
timing information of the DECT network quickly 

Dedicated ULE "dummy" C/L channel using the B-field of regular dummy bearer containing: 

■ Aids for fast re-synchronization 

■ General static broadcast information 

■ Channel selection information 

■ Dedicated ULE paging channels 

■ Provision for connectionless downlink channels (in further phases) 

Ultra-fast "expedited" procedures optimized for ULE and allowing combined transmission of signalling 
and data packet in the very first frame 

New paging channels specific for ULE over extended dummy bearer 

Implementing a wide range of modes from fast to ultra-slow paging 

Management algorithms for handling access collisions 

Use of short slots if no U-data for further energy saving 

"Stay-alive" handshake procedures 

U-plane based on MAC protected service Ipqr 

■ Error detection (CRC) and correction (ARQ) capabilities 
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■ Automatic retransmission based on a Mod-2 schema with a maximum packet Ufetime 

• DLC Layer 

New DLC service LU14 incorporating CCM authenticated encryption at DLC layer 

■ See also security description 

DLC service LUlO with frames FUlOa/d as transport of LU14 

■ Provides sequence numbering and control, flow control, Tx/Rx window handling, and 
segmentation and re-assembling, of higher layer packets 

New channel Gfa for DLC control 

C-plane DLC (LAPC) service 

• Network (NWK) Layer 

Connection Oriented model including CC (Call Control) and MM (Mobility Management) entities 

■ Virtual Circuits (=PDP Context) created at the beginning and kept for long time 

■ No NWK layer operations during regular packet handling 
DECT CC message and operations support 

DECT MM message and operations support 

■ Location update, authentication, etc. 

■ Some restrictions will be applicable in phase 1 by practical reasons 
Additional lEs for negotiation of higher layer (application) protocol 

• Stateof the art Security 

NWK layer authentication algorithm DSAA2 based on AES with key length 128 bits (see 
EN 300 175-7 [7]): 

■ Provides both PT and FT mutual authentication and Cipher Key generation 

■ Split into two security processes in NWK side allowing geographic distribution in home/visited 
domains 

New authenticated encryption based on CCM operating at DECT DLC layer: 

Based on RFC 3610 [i.7] and AES 128 [i.8] 

■ Provides simultaneously strong encryption and continuous mutual authentication without the need 
of running NWK layer transactions 

■ Mechanism ideal for the intended application 

The following three types of PP devices are part of DECT ULE phase 1 . Additional device types may be added in 
further ULE phases: 

• PP type I: "sensor" with or without paging support 

• PP type II: "fast actuator" 

• PP type III: "slow actuator" 

Examples of the applications that can be built with DECT ULE phase 1 (the present document) are the following: 

• Actuator devices 

Devices with fast response times (Fixed Part to Portable Part and vice versa) commonly used, for instance, in 
Electricity Plugs or Motor Drivers such as a sunscreen. 
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• Slow Actuator devices 

Devices with relatively fast response times (Fixed Part to Portable Part and vice versa) commonly used, for 
instance, in Thermostats. 

• Sensor devices 

Devices with long sleep times and fast response times from Portable Part to Fixed Part. Typical examples are 
Smoke Detectors and Motion Detectors. 

This list is not exhaustive and further applications may be developed by device vendors based on the present document. 

The maximum radio coverage range of DECT ULE will be as wide as standard DECT technology. Smaller coverage 
may be defined for specific applications due to power consumption and spectrum use considerations. 

Due to the nature of DECT ULE applications, it is foreseen that most of them would operate, however not necessarily, 
over unlicensed spectrum. The standard DECT frequency allocation (1 880 - 1 900 MHz) will be used in EU area for 
operation of ULE phase 1 devices. Further bands, licensed or unlicensed, may be identified in the future. 

DECT ULE has been designed to be coexistent with other DECT applications (including GAP or NG-DECT). Different 
types of DECT devices may be used over the same spectrum, and mixed devices supporting DECT ULE and other 
DECT applications may be built. It is foreseen that the majority of DECT ULE RFPs and some DECT ULE PPs will be 
mixed devices. 

All DECT devices claiming to be compliant with this Application Profile will offer at least the basic services defined as 
mandatory. In addition to that, optional features can be implemented to offer additional DECT ULE services. 

The aim of the present document is to guarantee a sufficient level of interoperability and to provide an easy route for 
development of DECT ULE applications, with the features of the present document being a common fall-back option 
available in all compliant to this profile equipment. The present document also guarantees compatibility between DECT 
ULE applications and existing DECT applications (such as GAP or NG-DECT) running over the same spectrum and 
even in the same device. 

DECT ULE does not standardize high layer (application) data protocols, which may be defined by separate ETSI 
documents or may be in the scope of other standardization organizations. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
referenced document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] ETSI EN 300 175-1: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 1: Overview". 

[2] ETSI EN 300 175-2: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 2: Physical layer (PHL)". 

[3] ETSI EN 300 175-3: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 3: Medium Access Control (MAC) layer". 

[4] ETSI EN 300 175-4: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 4: Data Link Control (DEC) layer". 
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[5] ETSI EN 300 175-5: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 5: Network (NWK) layer". 

[6] ETSI EN 300 175-6: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 6: Identities and addressing". 

[7] ETSI EN 300 175-7: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 7: Security features". 

[8] ETSI EN 300 175-8: "Digital Enhanced Cordless Telecommunications (DECT); Common 

Interface (CI); Part 8: Speech and audio coding and transmission". 

[9] ETSI EN 300 444: "Digital Enhanced Cordless Telecommunications (DECT); Generic Access 

Profile (GAP)". 

[10] ETSI EN 300 176-1: "Digital Enhanced Cordless Telecommunications (DECT); Test 

specification; Part 1: Radio". 

[11] ETSI EN 301 406: "Digital Enhanced Cordless Telecommunications (DECT); Harmonized EN for 

Digital Enhanced Cordless Telecommunications (DECT) covering the essential requirements 
under article 3.2 of the R&TTE Directive; Generic radio". 

[12] ETSI EN 301 908-10: "Electromagnetic compatibility and Radio spectrum Matters (ERM); Base 

Stations (BS), Repeaters and User Equipment (UE) for IMT-2000 Third-Generation cellular 
networks; Part 10: Harmonized EN for lMT-2000, FDMA/TDMA (DECT) covering essential 
requirements of article 3.2 of the R&TTE Directive". 

[13] ETSI TS 102 527-3: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 3: Extended Wideband Speech Services". 

[14] ISO/IEC 8073 (1997): "Information technology — Open Systems Interconnection — Protocol for 

providing the connection-mode transport service". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

[i.l] ETSI TR 101 178: "Digital Enhanced Cordless Telecommunications (DECT); A high Level Guide 

to the DECT Standardization". 

[i.2] ETSI TBR 006: "Digital Enhanced Cordless Telecommunications (DECT); General terminal 

attachment requirements". 

[i.3] ISO/IEC 9646-6: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 6: Protocol profile test specification". 

[i.4] ISO/IEC 9646-7: "Information technology - Open Systems Interconnection - Conformance testing 

methodology and framework - Part 7: Implementation Conformance Statements". 

[i.5] ETSI EN 301 649: "Digital Enhanced Cordless Telecommunications (DECT); DECT Packet 

Radio Service (DPRS)". 

[i.6] ETSI TS 102 527-1: "Digital Enhanced Cordless Telecommunications (DECT); New Generation 

DECT; Part 1: Wideband Speech ". 

[i.7] IETF RFC 3610: "Counter with CBC-MAC (CCM)". 

[i.8] FIPS Publication 197 (2001): "Advanced Encryption Standard (AES)", National Institute of 

Standards and Technology (NIST). 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Access Rights Identity (ARI): globally unique identity that shows the access rights related to a service provider 

NOTE: See EN 300 175-6 [6]. 

attach: process whereby a PP within the coverage area of a FP to which it has access rights, notifies this FP that it is 
operative 

authentication: process whereby a DECT PT, FT or subscriber is positively verified to be a legitimate user of a 
particular DECT system 

bearer service: type of telecommunication service that provides a defined capability for the transmission of signals 
between user-network interfaces 

C-plane: control plane of the DECT protocol stacks, which contains all of the internal DECT protocol control, but may 
also include some external user information 

NOTE: The C-plane stack always contains protocol entities up to and including the NWK layer. 

call: all of the NWK layer processes involved in one NWK layer peer-to-peer association 

Cipher Block Chaining Message Authentication Code (CBC-MAC): cryptographic technique for constructing a 
message authentication code from a block cipher 

Counter with CBC-MAC (CCM): authenticated encryption algorithm designed to provide both authentication and 
confidentiality 

DECT network: network that uses the DECT air i/f to interconnect a local network to one or more portable 
applications. The logical boundaries of the DECT network are defined to be at the top of the DECT NWK layer 

expedited (messages, procedures, operations): MAC C/O operations (messages, procedures, operations) intended for 
ultra fast setup and release of bearers, allowing in most cases reduction in the number of messages and early or late U- 
plane transmission compared to regular procedures 

Fixed Part (DECT Fixed Part) (FP): physical grouping that contains all of the elements in the DECT network 
between the local network and the DECT air i/f 

NOTE: A DECT FP contains the logical elements of at least one FT, plus additional implementation specific 
elements. 

Fixed radio Termination (FT): logical group of functions that contains all of the DECT processes and procedures on 
the fixed side of the DECT air i/f 

NOTE: A FT only includes elements that are defined in the DECT Common Interface (CI) standard. This 
includes radio transmission elements together with a selection of layer 2 and layer 3 elements. 

geographically unique identity: related to FP identities, PARIs and RFPIs, it indicates that two systems with the same 
PARI, or respectively two RFPs with the same RFPI, cannot be reached or listened to at the same geographical position 

NOTE: For PARI and RFPI, see abbreviations clause. 

global network: telecommunication network capable of offering a long distance telecommunication service 

NOTE: The term does not include legal or regulatory aspects, nor does it indicate if the network is a public or a 
private network. 

globally unique identity: identity is unique within DECT (without geographical or other restrictions) 
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handover: process of switching a call in progress from one physical channel to another physical channel 

NOTE: Handover may be intra-cell handover or inter-cell handover. 

Home Automation Network (HAN): network that connects all sensors and actors in a house or apartment, providing 
interoperability for devices of different vendors and typically has a connection to the Internet. The Home Automation 
Network is used for various applications, from Home Automation and Security to Climate Control and Energy 
Management 

inter-cell handover: switching of a call in progress from one cell to another cell 

internal general call: internal call setup by a PP to ring all other PPs (i.e. excluding the initiator) and FP (when capable 
of) 

NOTE: This is typically useful in residential environments when transferring a call. 

internal handover: handover processes that are completely internal to one FT Internal handover reconnects the call at 
the lower layers, while maintaining the call at the NWK layer 

NOTE: The lower layer reconnection can either be at the Data Link Control (DLC) layer (connection handover) 
or at the Medium Access Control (MAC) layer (bearer handover). 

inter-operability: capability of FPs and PPs, that enable a PP to obtain access to teleservices in more than one Location 
Area (LA) and/or from more than one operator (more than one service provider) 

InterWorking Unit (IWU): unit that is used to interconnect sub networks 

NOTE: The IWU will contain the interworking functions necessary to support the required sub-network 
interworking. 

intra-cell handover: switching of a call in progress from one physical channel of one cell to another physical channel 
of the same cell 

link: association between two DLC layer entities 

NOTE: This can either be one DLC C-plane association or one DLC U-plane association. Usually, but not 
necessarily, one DLC Link is mapped to one Logical connection. 

locally unique identity: unique identity within one FP or LA, depending on application 

Location Area (LA): domain in which a PP may receive (and/or make) calls as a result of a single location registration 

location registration: process whereby the position of a DECT PT is determined to the level of one LA, and this 
position is updated in one or more databases 

NOTE: These databases are not included within a DECT FT. 

logical connection: association between two instances of the MAC MBC that can be used by higher layers to exchange 
U-plane or C-plane data 

logical connection establishment: procedure to create a logical connection 

NOTE: The logical connection establishment is instantiated by the DLC upon request of the NWK layer. 

logical connection release: procedure to release a logical connection 

NOTE: The logical connection release is usually instantiated by the DLC upon request of the NWK layer, but 
under certain circumstances it could also be initiated by the ME. 

MAC connection (connection): association between one source MAC Multiple Bearer Control (MBC) entity and one 
destination MAC MBC entity 

NOTE: This provides a set of related MAC services (a set of logical channels), and it can involve one or more 
underlying MAC bearers. 

machine to machine solution: combination of devices, software and services that operate with little or no human 
interaction 
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Message Authentication Code (CCM): short piece of information generated by a cryptographic function used to 
authenticate and to protect the data integrity of a message 

Message Integrity Code (CCM): ahernative name for the Message Authentication Code 

multiframe: repeating sequence of 16 successive Time Division Multiple Access (TDMA) frames, that allows low rate 
or sporadic information to be multiplexed (e.g. basic system information or paging) 

New Generation DECT: further development of the DECT standard introducing wideband speech, improved data 
services, new slot types and other technical enhancements 

outgoing call: call originating from a PP 

Packet Data Protocol (PDP): terminology used in GPRS and 3GPP that refers to any of the data protocols transported 
over the radio packet service (IP, X.25, etc.) 

PDP context: terminology used in GPRS and 3GPP to denote the context associated to a packet data connection. It is 
equivalent to "virtual circuit" 

Permanent Virtual Circuit (PVC): Virtual Circuit that can be established and cleared only by configuration 

physical connection: association between two sets of TBCS at MAC layer including the underlying bearers that belong 
to a single logical connection 

physical connection establishment: procedure to activate all bearers and TBCs related to a single logical connection 
NOTE: The Physical Connection establishment is always under control of the Management Entity (ME). 

physical connection release: procedure to release all bearers and TBCs associated with a Logical connection 

NOTE: Physical Connection release is always under control of the Management Entity (ME). 

Portable Part (DECT Portable Part) (PP): physical grouping that contains all elements between the user and the 
DECT air i/f 

NOTE 1 : PP is a generic term that may describe one or several physical pieces. 

NOTE 2: A DECT PP is logically divided into one PT plus one or more PAs. 

Portable radio Termination (PT): logical group of functions that contains all of the DECT processes and procedures 
on the portable side of the DECT air i/f 

NOTE: A PT only includes elements that are defined in the DECT CI standard. This includes radio transmission 
elements (layer 1) together with a selection of layer 2 and layer 3 elements. 

Radio Fixed Part (REP): one physical sub-group of a FP that contains all the radio end points (one or more) that are 
connected to a single system of antennas 

registration: ambiguous term that should always be qualified. See either location registration or subscription 
registration 

resume: procedure to re-establish the physical connection for a logical connection in suspended state 

resumed state: state of an established Logical connection, open at MB, DLC and NWK, with active TBCs and physical 
layer 

roaming: movement of a PP from one FP coverage area to another FP coverage area, where the capabilities of the FPs 
enable the PP to make or receive calls in both areas 

NOTE: Roaming requires the relevant FPs and PP to be inter-operable. 
RS: value used to establish authentication session keys 
subscription registration: infrequent process whereby a subscriber obtains access rights to one or more FPs 

NOTE: Subscription registration is usually required before a setting any Virtual Call. 
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suspend: procedure to release the physical connection without releasing the logical connection 

suspended state: state of an established logical connection open at MBC, DLC and NWK but with no associated TBCs 
and physical layer resources 

TDMA frame: time-division multiplex of 10 ms duration, containing 24 successive full slots 

NOTE: A TDMA frame starts with the first bit period of full slot and ends with the last bit period of full slot 23. 

Ultra Low Energy (ULE): packet data technology based on DECT intended for M2M communications and optimized 
for ultra low power consumption under low or moderate data rate and traffic conditions 

Virtual Call (VC): any packet-mode user connection that can be setup and released by means of NWK layer C-plane 
procedures 

NOTE 1 : A Virtual Call is the packet-mode equivalent of a circuit-mode call. 

NOTE 2: Virtual Call is the DECT terminology for what in GPRS and UMTS is called "PDP context". 

virtual circuit: any packet-mode user connection able to transport the user packet data protocol. Each Virtual Circuit 
provides an independent and isolated context for each subscriber data session and is mapped to one DLC Link and to 
one MAC Logical connection 

NOTE 1: Virtual circuits could be of two types: Virtual Calls (VC) and Permanent Virtual Circuits (PVC). 

NOTE 2: A Permanent Virtual Circuit is the packet-mode equivalent of a circuit-mode leased line. A PVC is a 
degenerated case of a VC. 

3.2 Symbols and abbreviations 

For the purposes of the present document, the following symbols, terms and definitions apply: 



AC 

ACK 

AES 

AP 

ARI 

ARQ 

BA (bits) 

BCK 
Bs 

Bu 

C 

C 

C/L 

CA 

CBC-MAC 

CC 

CCM 

Cp 

CHO 

CI 

CLMS 

C-plane 

CRC 

Cs 

DCK 

DECT 

DF 

DLC 

DPRS 



Authentication Code 

ACKnowledgement 

Advanced Encryption Standard 

Application Profile 

Access Rights Identity 

Automatic Retransmission reQuest 

B-field identification bits, the bits from the A-field header that provide indication for the content 

of the B-field of one MAC layer packet 

bit used for Ip channel flow control in MAC Ip error correction services 

Slow Broadcast channel 

ULE Broadcast channel 

for conditional to support (process mandatory) 

higher layer control Channel (see Cg and Cp) 

ConnectionLess 

Channel Active 

Cipher Block Chaining Message Authentication Code 

Call Control, a NWK layer functional grouping. 

Counter with CBC-MAC 

higher layer signalling Channel (Fast) 

Connection HandOver 

Common Interface 

ConnectionLess Message Service 

Control plane 

Cyclic Redundancy Check 

higher layer signalling Channel (Slow) 

Derived Cipher Key 

Digital Enhanced Cordless Telecommunications 

DECT Forum 

Data Link Control 

Data Packet Radio service 



£75/ 



20 



ETSI TS 102 939-1 VI. 1.1 (2013-04) 



DSAA 

DSAA2 

DSC 

DSC2 

E+U 

ECN 

EFREL 

EMC 

FCNT 

FLEN 

FMID 

FP 

FT 

GAP 

Gp 

GpA 

GFSK 

GPRS 

HAN 

HD 

HLM 

HTTP 



IE 

IETF 

i/f 

^P 
IP 
IpF 



IpMR 

IpQ 
^PQR 

IWU 

KSG 

L 

LA 

LAPC 

LBN 

Lc 

LCE 

LLME 

LLN 

LSB 

LSIG 

LU 

M 

M 

MO 

Ml 

M2 

MAC 

MAC 

MBC 



DECT Standard Authentication Algorithm 

DECT Standard Authentication Algorithm #2 

DECT Standard Cipher (algorithm) 

DECT Standard Cipher #2 (algorithm) 

Mode of the B-field E/U multiplexer carrying U-plane data and signalling 

Exchanged Connection Number 

Enhanced Frame RELay service 

Equipment Manufacturer's Code 

Frame CouNTer 

Frame LENgth 

Fixed part MAC IDentity 

Fixed Part 

Fixed radio Termination 

Generic Access Profile 

higher layer information control channel (fast) (a logical channel to the MAC layer) 

higher layer information control channel (slow) (a logical channel to the MAC layer) 

Gaussian Frequency Shift Keying 

General Packet Radio Service 

Home Automation Network 

High Definition 

High Level Modulation 

HyperText Transfer Protocol 

for out-of-scope (provision optional, process optional) not subject for testing 

higher layer Information channel (see l^ and Ip) 

Information Element 

Internet Engineering Task Force 

interface 

higher layer Information channel (unprotected) 

higher layer Information channel protected (in general, any variant) 

Internet Protocol 

higher layer Information channel (protected) transported multiplexed with signalling in the E+U 

type slots 

higher layer Information channel, multi-subfield (protected) B-field with error detection only 

higher layer Information channel, multi-subfield (protected) B-field with MOD-2 protected 

channel operation (ARQ) 

higher layer Information channel (protected) with single subfield format and error detection only 

higher layer Information channel (protected) with single subfield format and error correction using 

MOD-2 retransmission mechanism 

InterWorking Unit 

Key Stream Generator 

Length 

Location Area 

DLC layer C-plane protocol entity 

Logical Bearer Number 

a DLC layer C-plane protocol entity 

Link Control Entity 

Lower Layer Management Entity 

Logical Link Number 

Least Significant Bit 

LSIG Link SIGnature 

DECT DLC U-Plane Service 

for mandatory to support (provision mandatory, process mandatory, see clause 6.2.1). 

MAC control channel 

RFP channel pre-selection algorithm for ULE 

PP channel selection algorithm for ULE 

PP collision handling and avoidance algorithm for ULE 

Medium Access Control 

Message Authentication Code (CCM) 

Multi Bearer Control 
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MCEI 

ME 

MF 

MFN 

MIC 

MM 

MOD 

M^ 

MTU 

Mu 
MUX 

N 
N/A 

NG-DECT 

NLF 

Ns 
Nx 

NTP 

NWK 

O 

0.x 

P 

PAP 

PARI 

PDP 

PDU 

PHL 

PHY 

PIN 

PMID 

PP 

PP 

PSCN 

PSTN 

Pt 
PT 

Pu 

PVC 

Q 

Qc 

Qh 

Qt 

RES 

RFC 

RFP 

RFPI 

RN 

RR 

RSSI 

Rx 

SAP 

SAPI 

SARI 

SDU 

Sip 

SIP 
SN 
TBC 



MAC Connection Endpoint Identifier 

Management Entity 

Multi Frame 

MultiFrame Number 

Message Integrity Code (CCM) 

Mobility Management 

MODulus 

MAC control channel on A-tail field, or one message on such channel 

Maximum Transmission Unit 

MAC control channel on B -field for ULE 

time Multiplexors 

identities channel 

for not-applicable (in the given context the specification makes it impossible to use this capability, 

see clause 6.2.1). 

New Generation DECT 

New Link Flag 

split identities channel on B -field for ULE 

identities information channel or one message in such channel 

Normal Transmitted Power 

NetWorK 

for optional to support (provision optional, process mandatory, see clause 6.2.1) 

option comprising number of items 

Paging channel 

PAP Pubhc Access Profile 

Primary Access Rights Identity 

Packet Data Protocol 

Protocol Data Unit 

PHysical Layer 

PHYsical 

Personal Identity Number 

Portable part MAC IDentity 

DECT Portable Part 

Portable Part 

Primary receiver Scan Carrier Number 

Public Switched Telephone Network 

one P-channel message 

Portable radio Termination 

ULE Paging channel on B -field 

Permanent Virtual Circuit 

system information channel 

Compound System Information Channel of B-field for ULE 

Q field header 

system information and Multiframe marker 

RESponse 

Request For Comment 

Radio Fixed Part 

Radio Fixed Part Identity 

Received sequence Number 

a frame type of the DLC C-plane entity 

Radio Signal Strength Indicator 

Receiver side 

Service Access Point 

Service Access Point Identifier 

Secondary Access Rights Identity 

Service Data Unit 

higher layer connectionless channel (protected) 

Session Initiation Protocol 

Slot Number 

Traffic Bearer Control 
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TDMA Time Division Multiple Access 

Tx Transmitter side 

UAK User Authentication Key 

ULE Ultra Low Energy 

UMTS Universal Mobile Telecommunication System 

UPI User Personal Identification 

U-plane User-plane 

VC Virtual Call 

X excluded, not allowed 



4 Description of services 

4.1 DECT Ultra Low Energy 



4.1.1 



Introduction 



Digital Enhanced Cordless Telecommunications (DECT) technology was launched in 1987 and has since then 
developed into one of the most reliable and flexible digital radio access standard for cordless communication. DECT 
has been a continuously evolving technology and new versions of the core technology such as New Generation DECT- 
(NG-DECT) have already surfaced. It has added features such as HD voice, VoIP and other internet based services over 
the standard DECT protocol. 

DECT ULE is based on the proven and established DECT standard. ULE has all the traditional strengths of DECT 
(interference free, license free, security, authentication, long range, ready internet etc). With re-designed hardware and 
software components DECT ULE is optimized for low data rate application and ultra-low power consumption. DECT 
ULE is compatible with DECT voice applications, such as GAP [9] or NG-DECT, allowing the support of both services 
in the same system and the design of mixed mode PPs or RFPs. 

DECT ULE is designed to maintain a good Quality of Service (which is a unique feature of ULE compared to other low 
power wireless standards). The low energy (ULE) version positions DECT in new and rapidly growing market 
segments beyond the traditional DECT telephony market, such as the wireless Machine-to-Machine (M2M) market - a 
rapidly growing segment. 

DECT Ultra Low Energy is the DECT base specification for the low power applications. DECT ULE includes powerful 
mechanisms providing context control, mobility management and security, and takes advantage of powerful features of 
the DECT common interface to offer a high performance data transport mechanism. 

The present document defines the base functions for DECT ULE and the specific functions for "Home Automation 
Network (phase 1)". The present document provides a selection of features, operation modes and interworking functions 
and defines an interoperability profile. 

4.2 ULE phase 1 

4.2.1 Definition of ULE phase 1 

DECT ULE phase 1 is defined as a specific DECT ULE capability set that provides solutions intended primarily, but 
not necessarily, for Home Automation scenarios. 

DECT ULE phase 1 consists on three types of PP devices (or device functionalities) named type 1: "sensor", type 2: 
"fast actuator" and type 3: "slow actuator" plus a ULE phase 1 enabled REP. See clause 4.3.1 for description of the ULE 
phase 1 device types. All these device types may also implement other DECT functionalities. For example, an ULE 
compliant RFP may, at the same time, be a GAP or NG-DECT RFP. 
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4.2.2 Example of applications covered by ULE phase 1 

Examples of the applications that can be built with DECT ULE phase 1 (the present document) are the following: 

• Actuator devices 

Devices with fast response time requirements and traffic usually FT initiated, such as electricity plugs, electric 
control elements, alarm centrals and other control elements. 

• Slow Actuator devices 

Devices with medium response time requirements and traffic usually FT initiated, commonly used, for 
instance, in heating and air conditioning systems. 

• Sensor devices 

Devices with long sleep times, very demanding power consumption requirements, fast response time 
requirements for PP originated events and slow response time requirements for FP initiated actions. Typical 
examples are switches and puss buttons, command modules, thermostats, smoke detectors and motion 
detectors. 

This list is not exhaustive and further applications may be developed by device vendors based on the present document. 

4.2.3 Physical layer, radio properties and spectrum use 

The maximum radio coverage range of DECT ULE will be as wide as standard DECT technology. Smaller coverage 
may be defined for specific applications due to power consumption and spectrum use considerations. 

Due to the nature of DECT ULE applications, it is foreseen that most of them would operate, however not necessarily, 
over unlicensed or license exempt spectrum. The standard DECT frequency allocation (1 880 - 1 900 MHz) will be used 
in EU area for operation of ULE phase 1 devices. Further bands, licensed or unlicensed, may be identified in the future. 

DECT ULE has been designed to be coexistent with other DECT applications (including GAP or NG-DECT). Different 
types of DECT devices may be used over the same spectrum, and mixed devices supporting DECT ULE and other 
DECT applications may be built. It is foreseen that the majority of DECT ULE RFPs and some DECT ULE PPs will be 
mixed devices. 

4.2.4 Coexistence with other DECT services 

DECT ULE has been designed to be coexistent with other DECT applications (including GAP or NG-DECT). Different 
types of DECT devices may be used over the same spectrum, and mixed devices supporting DECT ULE and other 
DECT applications may be built. It is foreseen that the majority of DECT ULE RFPs and some DECT ULE PPs will be 
mixed devices. 

4.3 Reference scenarios for DECT ULE phase 1 

The following figures show examples of the applications scenarios that can be covered by DECT ULE phase 1 . 

4.3.1 Security applications (fire and burglary alarms) 

Figure 1 shows a typical security application scenario. External communications (via PSTN or internet) may be part of 
the scenario and easily implemented due to the usual PSTN or internet connectivity of most DECT RFPs. 
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detector i 

(Bedroom I) ] 



Fire department 
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Broadband 
Gateway 

(DECT ULE enabled! 

Figure 1 : Security application scenario (fire and burglary alarms) 

4.3.2 Global Home control and domotic scenario 

Figure 2 shows a Home control and domotic scenario. Sensor type and actuator type ULE devices are combined with 
specific appHcation logic to perform a potentially large number of functions in a home scenario. DECT advanced voice 
terminals such as New Generation DECT parts 3 or 5, and external connectivity via internet may also be part of the 
solution. 
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Figure 2: Global Home control and domotic scenario 



ETSI 



25 



ETSI TS 102 939-1 VI. 1.1 (2013-04) 



4.3.3 Energy and appliances management scenario 

Energy control is a target application of DECT ULE phase 1 . Figure 3 shows an energy and appliances management 
scenario in a domestic environment. Sensor type and actuator type ULE devices are used to perform multiple energy 
control related functions. Interconnection to utility companies via internet may be part of the solution. 
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Figure 3: Energy and appliances management scenario 

4.4 Requirement specification for ULE phase 1 
4.4.1 ULE phase 1 device types 

ULE phase 1 supports the following types of devices: 

• REP with support of ULE phase 1 

• PP type I: "sensor" 

• PP type II: "fast actuator" 

• PP type III: "slow actuator" 



4.4.1.1 



PP type I: "sensor" 



4.4.1.1.1 General description 

ULE PP devices, generally battery powered, with long sleep times and strong power saving requirements. 

Typical examples are sensors (all types). Smoke Detectors, Motion Detectors, temperature sensor, switches and press 
buttons, command modules, etc. 

4.4.1 .1 .2 Requirements and functionalities for type I devices 

ULE type I "sensor" PPs has the following requirements and specific functionalities: 
• Ultra low power consumption 
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• Unlocked "deep sleep" operation 

• Ultra low paging cycles (type la) or no paging cycle at all (type lb) 

• Fast response times when activated due to an event at the PP side 

4.4.1.2 PP type 1 1 : "fast actuator" 

4.4.1.2.1 General description 

ULE PP devices, generally line powered, with not so strong power saving requirements, but requiring fast response 
times as response to FP side orders. 

Typical examples are electric control modules (actuators) driving powers circuits, air conditioning equipment, alarm 
bells and control modules, etc. 

4.4.1 .2.2 Requirements and functionalities for type II devices 

ULE type II "fast actuator" PPs have the following requirements and specific functionalities: 

• Locked operation 

• Normal or fast paging cycles 

• High paging capacity 

• Fast response times as response to paging commands from the FP side 

4.4.1.3 PP type III: "slow actuator" 

4.4.1.3.1 General description 

ULE PP devices, battery or powered, with power saving requirements, but with traffic dominated by order from the FP 
and requiring medium response times as response to FP side orders. 

Typical examples are control modules (actuators) for heating (hot water circuit radiator) and air conditioning 
equipment. 

4.4.1 .3.2 Requirements and functionalities for type III devices 

ULE type III "slow actuator" PPs have the following requirements and specific functionalities: 

• Locked or un-locked operation 

• Normal to slow paging cycles 

• Medium paging capacity 

• Medium response times as response to paging commands from the FP side 

4.4.1 .4 ULE phase 1 compliant RFP 
4.4.1.4.1 General description 

A DECT RFP supporting the functionalities described in the present document. 

The RFP will typically support other DECT services such as GAP or New Generation DECT (any phase), however this 
is not mandatory. 
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4.4.1 .4.2 Requirements and functionalities for ULE pliase 1 RFP 

ULE phase 1 RFP has the following requirements and specific functionalities: 
General coexistence requirement: 

• It should be possible the implementation of REP supporting at the same time, ULE phase 1 and a DECT voice 
service (GAP or New Generation DECT). 

Specific ULE phase 1 requirements: 

• All RFPs compliant with the present document shall be able to support the three described types of ULE PPs. 

4.4.2 U-plane interworking and protocol architecture 
4.4.2.1 ULE phase 1 protocol architecture 

Figure 4 shows the protocol architecture of DECT ULE phase 1 . 

An external protocol (application layer) is transported over LU14 by means of an Interworking layer. The DECT 
C-plane may be activated as response to external application protocol when needed. 

In ULE phase 1, the only Interworking defined provides the transparent transport of the external protocol packet and the 
DECT C-plane is used to configure interworking parameters. Other more complex interworkings may be defined in 
further phases and releases. 




Figure 4: Reference model of the ULE U-plane and C-plane 



4.4.3 Performance Objectives 

Table 1 shows the performance objectives of DECT ULE phase 1. 



Table 1 : Performance objectives 



Performance 


Value 


Notes 


Maximum data rate for full-slot devices 


24 kbit/s 




Maximum data rate for double-slot devices 


64 kbit/s 




Response time for a PP => FP transmission when the PP was in 
locked state 


20 ms 




Response time for a PP => FP transmission when the PP was in 
deep sleep (unlocked) state (sensor type device) 


30 ms 
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Performance 


Value 


Notes 


Response time for a FP => PP transmission (fast actuator type 
device) 


50 m 




Paging cycle for sensor type devices 


Configurable: 160 ms to 
60 min plus infinite 




Paging cycle for slow actuator devices 


Configurable: 160 ms to 
10 min 




Paging cycle for fast actuator devices 


Configurable: 10 ms to 
160 ms 




Stay alive cycle 


Configurable: 640 ms to 
60 min plus infinite 





Table 2: Void 

4.5 Technical features implemented by ULE phase 1 

DECT Ultra Low Energy (ULE) Part 1 (the present document) provides the following basic functionalities. 

4.5.1 IVIAC/PHY layer 

C/O MAC service with capability of suspend/resume via expedited operations: 

• Advanced connection setup 

• Advanced connection release 

• Full slot 

• Short slot 

• MAC format IpQ 
Expedited ULE C/O operations: 

• Ultra-fast "expedited" procedures optimized for ULE and allowing combined transmission of signalling and 
data packet in the very first frame 

• Expedited Access Request, Ready for Release and Release commands 

• Expedited operations optimized for short burst data transfer 

• Expedited operations optimized for multi-burst data transfer 

• Optional use of short slots (POO) for power saving when no data is transported on B-field 

• Management algorithms for channel selection and handling access collisions 
Transport of higher layer signalling: 

• Transport of channel Cg over A-field of ULE C/O bearers 

• Transport of channel Cp (optional) over B-field of ULE C/O bearers 

• Transport of channel Gp^ over A-field of ULE C/O bearers 

Dedicated ULE "dummy" C/L channel using the B-field of regular dummy bearer containing: 

• Aids for fast re-synchronization 

• General static broadcast information 

• Channel selection information 



£75/ 



29 ETSI TS 1 02 939-1 V1 .1 .1 (201 3-04) 

• Dedicated ULE paging channels 

• Provision for connectionless downlink channels (in further phases) 

• Capability for changing the position of the dummy bearer 

Unlocked, ultra low duty cycle operation for battery powered Portable Part devices: 

• PP may enter in "deep sleep" state between activity cycles with near all circuits switched off (with loss of 
synchronization to the base ) 

• Provisions for Fast Locking so the Portable Part devices can remain in long sleep cycles and regain the timing 
information of the DECT network quickly 

New paging channels specific for ULE over extended dummy bearer: 

• Implementing a wide range of modes from fast to ultra-slow paging 

• Separate channels from existing DECT LCE paging over A-field 

• High capacity: a large number of sensor, fast and slow actuator devices can be paged 

• Provision for future broadcast channels 
U-plane handling: 

• MAC MOD-2 protected channel operation (service Ipqr error_correct) 
"Stay-alive" handshake procedures. 

4.5.2 DLC layer 

DEC C-plane 

• C-plane DLC (LAPC) as in existing DECT 
DLC U-plane 

• New DLC service LU14 adding a CCM authenticated encryption layer based on existing service LUlO 

Provides sequence numbering and control, flow control, Tx/Rx window handling, and segmentation and 
re-assembling, of higher layer packets 

See also security description 

• Class 1 transmission protocol 

• New channel GFA for DLC control 

4.5.3 NWK layer 

• Connection Oriented model including CC (Call Control) and MM (Mobility Management) entities 

Configurable Virtual Circuits (= PDP Context) created at the beginning and kept for long time 
No NWK layer operations required during regular packet handling 

• DECT CC message and operations support 

Simplified NWK CC procedures for Virtual Circuit control with optimized state machine 

• DECT MM message and operations support 

Location update, authentication, etc. 
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Some restrictions (e.g. inter-cell handover) are applicable in phase 1 

• Additional lEs for negotiation of higher layer (application) protocol 

4.5.4 Interworking and Application layer 

Transparent interworking allowing the use of external protocols with packet size of up to 500 octets. 

4.5.5 Security 

NWK layer authentication algorithm DSAA2 based on AES [i.8] with key length 128 bits (see EN 300 175-7 [7]): 

• Provides both PT and FT mutual authentication and Cipher Key generation. 

• Split into two security processes in NWK side allowing geographic distribution in home/visited domains. 
New authenticated encryption based on CCM operating at DECT DLC layer: 

• Strong packet encryption mechanism providing packet sequence integrity based on AES algorithm with key 
length 128 bits and dynamic key generated by the DSAA2 authentication algorithms. 

• Based on RFC 3610 [i.7] and AES [i.8] with key length 128 bits. 

• Provides simultaneously strong encryption and continuous mutual authentication without the need of running 
NWK layer transactions. 

4.5.6 Management entity 

Management entity processes for: 
Channel selection 
Handling of collisions 
Handling of other errors 
Rules for resume 
Rules for suspend, sending Ready for Release, Release, etc. 



Relevant requirements 



In any case, the requirements of EN 300 176-1 [10] and any of the harmonized standard EN 301 406 [11] shall apply as 
well. 

5.1 Service and feature definitions 

For the purposes of the present document the following service and feature definitions apply. 

5.1.1 PHL service definitions 

For the purpose of the present document, the following definitions shall apply. 

GFSK modulation [ULEl-P.l]: 2 level Gaussian frequency Shift Key (GFSK) modulation as defined by 

EN 300 175-2 [2], clause 5. 

Physical Packet P32 [ULE1-P.2]: Physical packet P32 (full slot) as defined by EN 300 175-2 [2], clause 4.4.2. 
Physical Packet POO [ULE1-P.3]: Physical packet POO (short slot) as defined by EN 300 175-2 [2], clause 4.4.1. 
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General PHL [ULE1-P.4]: General Physical layer procedures applicable to all ULE terminals. 

ULE Transmitted power [ULE1-P.5]: Physical layer procedures defining the transmitted power applicable to all ULE 

terminals. 

Fast hopping radio [ULE1-P.6]: Radio transceiver able to perform frequency change during the interval between two 
consecutive Physical Packets P32 (full slot). 

5.1 .2 MAC service definitions 

For the purpose of the present document, the following definitions shall apply. 

General [ULEl-M.l]: set of basic requirements regarding data formats, multiplexing, CRC usage, scanning and 
locking, which are prerequisites to communication between peer MAC entities. 

A-field continuous broadcast [ULE1-M.2]: simplex service from FT to PT whereby the FT maintains at least one 
bearer with continuous transmissions. The PT can use the information carried in this bearer to lock to the FT and to 
obtain knowledge about the FT (service similar to GAP-M.2). 

A-field paging broadcast [ULE1-M.3]: service whereby the identities of specific PTs can be broadcasted by the FT. 
This service is normally used by the FT to request a specific PT to setup a link to the FT (service similar to GAP-M.3). 

B-field continuous ULE broadcast [ULE1-M.4]: simplex service from FT to PT whereby the FT broadcasts 
additional information, specific for the ULE service, using part of the B-field of the same bearer(s) used for service 
ULE.M.3. The PT can use the information carried in this bearer to lock to the FT and to obtain knowledge about the FT. 

B-field paging broadcast [ULE1-M.5]: service whereby the identities of specific PTs can be broadcasted by the FT 
using ULE specific broadcast procedures and broadcast channels over B-field. This service is normally used by the FT 
to request a specific PT to setup a link to the FT. 

Basic connection control [ULE1-M.6]: MAC control procedures using the basic control set, providing means for 
setting-up and releasing a basic connection. Basic connections used in the present document are single bearer, full slot, 
no Cp and may transport an U-plane with Ij^^_minimum_delay data service (i.e. speech), or no U-plane at all (service 
calls). Only one basic connection may exist between a FT and particular PT. 

A-field advanced connection control [ULE1-M.7]: MAC control procedures providing complete MAC support of 
single bearer connections using the advanced connection control set.MAC connections used in ULE use advanced 
control set (advanced connections) and may coexist with other advanced or basic connections for voice service between 
the same PT-FT pair. Several advanced connections may exist, however only one of them is controllable using ULE 
expedited operations. 

Expedited operations for advanced connection control [ULE1-M.8]: MAC control using expedited messages and 

procedures optimized for ultra low efficiency and power consumption. Expedited operations are used for ULE suspend 
and resume procedures. 

Full slot [ULE1-M.9]: support of the physical packet P32 and appropriate D-field mapping according to modulation 
type (D32a for GFSK modulation). 

IpQj{_error_correction MAC service type [ULEl.M.lO]: Ip_ error_correction symmetric or asymmetric service as 
defined in EN 300 175-3 [3], clauses 5.6.2.1 (type 4: Ip_ error_correction symmetric) and 5.6.2.2. 
(type 8: Ip_ error_correction asymmetric) with multi-subfield protected B-field as defined in EN 300 175-3 [3], 
clause 6.2.1.3.3 and Mod-2-protected channel operation as defined by EN 300 175-3 [3], clauselO.8.2. 

Short slot [ULEl-M.ll]: support of the physical packet POO and appropriate D-field mapping according to modulation 
type (DOOa for GFSK modulation). 

Gp^ channel [ULE1-M.12]: simplex channel transported in the A-field that is used to provide control and carry 
acknowledgements for DLC entities. 

C§ higher layer signalling [ULE1-M.13]: low rate connection oriented data service with ARQ using the C^ channel to 
transfer higher layer signalling data. 
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Cp higher layer signalling [ULE1-M.14]: high rate connection oriented data service with ARQ using the Cp channel 
to transfer higher layer signalling data. 

Quality control [ULE1-M.15]: provides means for monitoring and controlling the radio link quality. 

ULE physical channel selection [ULE1-M.16]: defines the policy for the dynamic selection of a channel, caused by 
the fact that an old one has to be changed or a new one is needed. Detection of bad quality on the physical channel in 
use (i.e. due to weak signals or interference), detection of a RFP with a stronger signal than the one of the own RFP, 
detection of local congestion are all criteria that can be used to select the channel. 

Secondary Access Rights Identity (SARI) support [ULE1-M.17]: ability to support, in addition to the primary 
Access Rights Identity (ARI), secondary ARIs that the FT broadcasts less frequently than PARIs. These may be used to 
reflect an inter-operators agreement allowing a portable to access more than one operator or services through FT 
(service similar to GAP-M.13). 

ULE bearer replacement intra-cell [ULE1-M.18]: bearer quality maintenance procedure by setting up a replacement 
bearer in the same RFP. Opposing to conventional voice channel handover, there is no requirement of using identical 
LBN and maintaining identical data on both bearers. Furthermore, the old bearer is released, before the setup of the new 
one. 

Dummy bearer replacement [ULE1-M.19]: bearer quality maintenance procedure by setting up a replacement for the 
dummy bearer in the same cluster. The old dummy bearer is released after the setup of the new one. 

Bearer handover inter-cell [ULE1-M.20]: connection quality maintenance by setting up replacement bearers in a 
different RFP belonging to the same cluster. Opposing to conventional voice channel handover, there is no the 
requirement of using identical LBN and maintaining identical data on both bearers. Furthermore, the old bearer is 
released, before the setup of the new one. 

Connection handover [ULE1-M.21]: connection quality maintenance by setting up replacement bearers in the same or 
a different cluster, each with identical LBN and maintaining identical data bearers with identical LBN. Subsequently the 
old bearers are released. 

Encryption activation [ULE1-M.22]: service providing means for enabling the encryption whereby on demand all 
higher layer data is transferred across the DECT air interface in an encrypted form. Always initiated by the PT. A 
connection release automatically disables ciphering (service similar to GAP-M.7). 

Encryption deactivation [ULE1-M.23]: service providing means for disabling the encryption whereby on demand all 
higher layer data is transferred across the DECT air interface in an encrypted form. A connection release automatically 
disables ciphering (service similar to GAP -M. 14). 

Re-keying [ULE1-M.24]: mechanism to change the cipher key during an ongoing virtual call or PVC. 

Early encryption [ULE1-M.25]: mechanism to activate encryption immediately after connection establishment. 

DSC encryption [ULE1-M.26]: encryption using the DSC algorithm. 

AES/DSC2 encryption [ULE1-M.27]: encryption using the DSC2 algorithm, based on AES, with Cipher Key of 128 

bits. 

5.1 .3 DLC service definitions 

For the purpose of the present document, the following definitions shall apply. 
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LU14 Enhanced Frame RELay service with CCM encryption (EFREL-CCM) [ULEl-D.l]: an enhanced frame 
relay service accessed through the LU14 SAP. LU14 adds CCM encryption on top of LUIO. LU14 encrypts the external 
message using CCM with AES algorithm and 128 bit key, adds a Message Integrity Code (MIC) of 32 bytes, and 
transfers the resulting structure to the LUIO SAP. All other properties of LUIO apply (except the option of operating 
with infinite size SDU that is not possible here). 

LU13 Enhanced Frame RELay service with CRC (EFREL-CRC) [ULE1-D.2]: an enhanced frame relay service 
accessed through the LU13 SAP. LU13 adds a CRC at SDU level, providing additional residual error detection 
capability, and transfers the resulting structure to the LUIO SAP. All other properties of LUIO apply (except the option 
of operating with infinite size SDU that is not possible here). 

LUIO Enhanced Frame RELay service (EFREL) [ULE1-D.3]: an enhanced frame relay service accessed through the 
LUIO SAP. The LUIO shall operate on a generic field of user data that shall be transferred into and out of the DLC 
U-plane as a single SDU. This SDU is assumed to contain one external frame, but the operation of LUIO shall be 
independent of the actual contents of the SDU. LUIO shall provide mechanisms that offer reliable transport of the 
generic SDUs, and that preserve the SDU boundaries. 

FUlOa [ULE1-D.4]: offers a defined fixed length frame structure and buffering functions for transmission of U-plane 
data to the MAC layer (at the transmit side) or accepts data from the MAC layer (at the receiving side) on demand and 
with minimum delay. Frame type FUlOa is used for the forward path of unidirectional links. Bi-directional links may be 
implemented using two unidirectional links. 

FUlOd [ULE1-D.5]: frame structure and buffering functions for transmission of higher layer U-plane control data from 
the DLC to the MAC layer channel (at the transmit side) or for accepting data from the MAC layer (at the receiving 
side). Used to carry acknowledgements or negative acknowledgement for connections. Frame type FUlOd is used for 
the backward control path of unidirectional links: it contains a single receive sequence number for the forward link. 
FUlOd is transported by MAC channel Gp^ using Mj control messages over A-field. There are two FUlOd frame 
formats depending on the transporting message. 

Data Link Service (LAPC + Lc) class A service [ULE1-D.6]: single frame acknowledged C-plane data link service 
providing a data link between one FT and one PT. The higher layer information is segmented (if necessary) and 
transmitted in numbered frames. The Lc service, upon which LAPC is defined, provides frame delimiting, transparency 
and frame synchronization (Service equivalent to GAP-D.l with modifications). 

DLC Transmission Class 1 [ULE1-D.7]: U-Plane DLC Transmission Protocol providing variable throughput service, 
with removal and notification of all errors detected at the MAC layer, resequencing and flow control. 

Lc Service [ULE1-D.8]: service providing channel dependant fragmentation, recombination, frame synchronization 
and frame delimiting transparency. Fragmentation is obtained by means of dividing a LAPC data unit into more than 
one service data units for delivery to the MAC layer C logical channel, whilst recombination is obtained by means of 
joining several service units received from the MAC layer C logical channel into a LAPC data unit. Allows the LLME 
to select the logical channel for Lc operation on a frame-by-frame basis. 

broadcast Lb service [ULE1-D.9]: simplex point-to-multipoint transmission using simple fixed length DLC frames 
providing a restricted broadcast service in direction FP to PP(s) (Service equivalent to GAP-D.3). 

encryption activation [ULEl-D.lO]: transporting the NWK layer encryption request and the cipher key to the MAC 

layer, thereby enabling the encryption process in the MAC layer (Service equivalent to GAP-D.6). 

encryption deactivation [ULEl-D.ll]: transporting the NWK layer encryption deactivation request to the MAC layer, 
thereby disabling the encryption process in the MAC layer (Service equivalent to GAP-D.9). 

CCM/AES encryption [ULE-D.12]: Encryption mechanism operating at DLC layer based on CCM with AES 
algorithm and Cipher Key of 128 bits. 

5.1.4 NWK feature definitions 

For the purpose of the present document, the following definitions shall apply. 



£75/ 



34 ETSI TS 1 02 939-1 V1 .1 .1 (201 3-04) 

ULE phase 1 NWK control [ULEl-N.l]: simplified NWK layer control procedures for ULE phase 1. 

ULE Service Call [ULE1-N.2]: call with only C-plane initiated by a DECT PT for entering of FT related service and 
adjustment procedures. 

authentication of PP [ULE1-N.3]: process by which the identity of a DECT PP is checked by the FP. 

authentication of user [ULE1-N.4]: process by which the identity of a user of a DECT PP is checked by the FP. The 
User Personal Identification (UPl), a personal identification of to 8 digits, manually entered by the user, is used for 
user authentication. 

location registration [ULE1-N.5]: facility whereby a PP can be registered with a FP or a cluster of FPs such that 
incoming calls, radio pages or messages may be routed to it. 

on-air key allocation [ULE1-N.6]: capability to transform Authentication Code (AC) into User Authentication Key 
(UAK) using the key allocation procedure. 

identification of PP [ULE1-N.7]: ability for the FP to request and PP to provide specific identification parameters. 

service class indication/assignment [ULE1-N.8]: assignment by the FP to PP of the service class and indication to the 
FP by the PP of the contents of its service class. 

encryption activation FT initiated [ULE1-N.9]: activation of the encryption process requested by FT. 

subscription registration procedure on-air [ULEl-N.lO]: standardized procedure for loading subscription 
registration data into a PP in real time over the air-interface. 

link control [N.ll]: ability to request, accept, maintain and release a data link for the purposes of a NWK layer 
procedure. 

terminate access rights FT initiated [ULE1-N.12]: ability of the FP to delete a subscription in the PP. 

authentication of FT [ULE1-N.13]: process by which the identity of a FP is checked by the PP. 

encryption activation PT initiated [ULE1-N.14]: activation of the encryption process suggested by PT. The real time 
start of ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation FT initiated [ULE1-N.15]: deactivation of the encryption process requested by FT. The real 
time stop of ciphering is done in the MAC layer and is always initiated by the PT. 

encryption deactivation PT initiated [ULE1-N.16]: deactivation of the encryption process suggested by PT. The real 
time stop of ciphering is done in the MAC layer and is always initiated by the PT. 

Enhanced Security [ULE1-N.17]: mechanism to enhance DECT security by introduction of early encryption and the 
possibility of re-keying during an ongoing call. 

AES/DSAA2 authentication [ULE1-N.18]: authentication using the DECT Authentication Algorithm #2 (DSAA2), 
based on AES, and including type 2 (see EN 300 175-7 [7]) air i/f procedures. 

5.1 .5 Application service definitions 

For the purpose of the present document, the following definitions shall apply. 

AC to bitstring mapping [ULEl.A.l]: mapping of the AC into a bitstring. 

Multiple subscription registration [ULE1.A.2]: ability of PP to store more than one subscription. 

Easy PIN code registration [ULE1.A.3]: ability to invite the user to register a PP that is not registered to a FP. The 
access rights procedure is triggered by PIN entering. 

5.1 .6 Management Entity (ME) definitions 

For the purpose of the present document, the following definitions shall apply. 
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ULE phase 1 Management [ULEl-ME.l]: inter and intra DECT protocol layers management of the phase 1 of the 
ULE protocol requirements that does incorporate a C-plane providing some MM and CC capabilities. 

ULE Physical Channel Selection [ULE1-ME.2]: management processes and algorithms in charge of physical channel 
selection in DECT ULE devices. 

5.1 .7 U-plane service and interworking definitions 

For the purpose of the present document, the following definitions shall apply: 

Transparent U-plane Interworking [ULEl-I.l]: provides the transparent transport of external protocol packets. C- 
plane configuration of the external protocol and MTU size are provided. 

5.1 .8 ULE 1 device types 

For the purpose of the present document, the following definitions shall apply. 

REP with support of ULE phase 1 [ULEl-TYP.l]: A DECT RFP with support of ULE phase 1 specification. Other 
DECT services, such as GAP or NG-DECT, may also be supported in the same RFP. 

PP type I "sensor" with paging support [ULE1-TYP.2]: ULE PP device type, generally battery powered, with long 
sleep times and strong power saving requirements. The device may be pageable using a very slow or ultra slow paging 
cycle. 

PP type I "sensor" without paging support [ULE1-TYP.3]: ULE PP device type, generally battery powered, with 
long sleep times and strong power saving requirements. The device does not listen to any paging channel in normal 
conditions. 

PP type II "fast actuator" [ULE1-TYP.4]: ULE PP device type, generally line powered, with not so strong power 
saving requirements, but requiring fast response times as response to FP side orders. 

PP type III "slow actuator" [ULE1-TYP.5]: ULE PP devices, battery or powered, with power saving requirements, 
but with traffic dominated by order from the FP and requiring medium response times as response to FP side orders. 



Profile specific requirements 



6.1 General 

The tables listed in this clause define the status of all protocol elements (i.e. features, services, and procedures), which 
can be: mandatory, optional, conditional under the provision of another protocol element, outside the scope of the 
present document, or not applicable. The status is identified by the status column designations defined in clause 3.2, and 
is described separately for FT and PT. 

All optional elements shall be process mandatory according to the procedures described in the present document. 

Protocol elements defined as mandatory, optional or conditional in this clause are further defined in the referenced 
DECT specification, or, if needed, in clause 7 of the present document. 
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In any case, the requirements of EN 300 176-1 [10], and any of the harmonized standards 

EN 301 406 [11] or EN 301 908-10 [12] shall be met by all equipment conforming to the present document. 

6.2 Specific conventions 

6.2.1 Use of symbols in support status tables 

The symbols defined in this clause are applied for procedures, features, and services in the present document if not 
explicitly otherwise stated. The interpretation of status columns in all tables is as follows: 

• "M" (provision mandatory, process mandatory) means that the indicated feature service or procedure shall be 
implemented as described in the present document, and may be subject to testing. 

• "O" (provision optional, process mandatory) means that the indicated feature, service or procedure may be 
implemented, and if implemented, the feature, service or procedure shall be implemented as described in the 
present document, and may be subject to testing. 

• "N/A" (not-applicable) means that, in the given context the specification, the use of this capability is 
meaningless or out of scope. 



NOTE: 



The used notation is based on the notation proposed in ISO/IEC 9646-7 [i.4]. 



6.3 DECT ULE phase 1 device types 

6.3.1 Types of devices supported by the present document 

The following types of DECT ULE phase 1 devices are supported by the present document. Additional device types 
may be added to further releases of the present document. 

Table 3: Types of DECT ULE phase 1 devices 



Item 


Name of service 


Reference 


Support status in a ULE 
system 


PT 


FT 


ULE1-TYP.1 


RFP with support of ULE phase 1 


5.1.8 


- 


M 


ULE1-TYP.2 


PP type 1 "sensor" with paging 
support 


5.1.8 


C301 


- 


ULE1-TYP.3 


PP type 1 "sensor" without paging 
support 


5.1.8 


C301 


- 


ULE1-TYP.4 


PPtype II "fast actuator" 


5.1.8 


C301 


- 


ULE1-TYP.5 


PP type III "slow actuator" 


5.1.8 


C301 


- 


C301 : At least one device type shall be used. 


NOTE: The reference column refers to the relevant clause in the present document. 



6.3.2 Specific procedures for specific device types 

All services, features and procedures described in the present document are applicable to all kinds of device types, 
except when otherwise stated. 

The present document defines only one type of RFP [ULEl-TYP.l]. Therefore, the support status of all services, 
features and procedures for FP is as given in tables 5 to 19. 

In regard to PP device types, most of services, features and procedures have the same support status for all kinds of 
devices. There are a few exceptions whose support status varies depending on the PP type. The status support of these 
procedures is given in table 4. 
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Table 4: Specific procedures for specific device types 



Device type 


Service or feature 


Procedure 


Reference 


Status 1 


PT 


FT 


PP type 1 "sensor" with 
paging [ULE1-TYP.2]: 












B-field Continuous ULE 
broadcast [ULE1-M.4] 


Operation in unlocked 
mode 


10.5.5 


M 


- 


B-field paging 
broadcast [ULE1-M.5] 


P(j Paging Message 
Formats 


10.6.1 


M 


- 


Paging Descriptors for 
ULE Paging 


10.6.2 


M 


- 


PP type 1 "sensor" 
without paging support 
[ULE1-TYP.3]: 












B-field Continuous ULE 
broadcast [ULE1-M.4] 


Operation in unlocked 
mode 


10.5.5 


M 




B-field paging 
broadcast [ULE1-M.5] 


P(j Paging Message 
Formats 


10.6.1 





- 


Paging Descriptors for 
ULE Paging 


10.6.2 





- 


PPtype II "fast 

actuator" 

[ULE1-TYP.4]: 












B-field Continuous ULE 
broadcast [ULE1-M.4] 


Operation in unlocked 
mode 


10.5.5 





- 


B-field paging 
broadcast [ULE1-M.5] 


P(j Paging Message 
Formats 


10.6.1 


M 


- 


Paging Descriptors for 
ULE Paging 


10.6.2 


M 


- 


PPtype III "slow 
actuator" [ULE1- 
TYP.5]: 












B-field Continuous ULE 
broadcast [ULE1-M.41 


Operation in unlocked 
mode 


10.5.5 


M 


- 


B-field paging 
broadcast [ULE1-M.5] 


P(j Paging Message 
Formats 


10.6.1 


M 


- 


Paging Descriptors for 
ULE Paging 


10.6.2 


M 


- 


NOTE: The reference column refers to the relevant clause in the present document. 



6.4 Physical layer (PHL) requirements 
6.4.1 Physical layer (PHL) services 

DECT Ultra Low Energy, phase 1 devices shall support the following Physical layer (PHL) services. 

Table 5: Physical layer service support 



Item 


Name of service 


Reference 


Support status 


PT 


FT 


ULE1-P.1 


GFSK modulation 


5.1.1 


M 


M 


ULE1-P.2 


Physical Packet P32 


5.1.1 


M 


M 


ULE1-P.3 


Physical Packet POO 


5.1.1 


M 


M 


ULE1-P.4 


General PHL 


5.1.1 


M 


M 


ULE1-P.5 


ULE Transmitted Power 


5.1.1 


M 


M 


ULE1-P.6 


Fast hopping radio 


5.1.1 








NOTE: The reference column refers to the relevant clause in the present document. 
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6.4.2 Modulation schemes 

The following modulation schemes defined by EN 300 175-2 [2], annex D shall be supported. 

Table 6: Allowed combinations of modulation schemes 



Modulation 
scheme 


S-field 


A-field 


B + Z-field 


Support status 


1a 


GFSK 


GFSK 


GFSK 


M 



6.4.3 PHL service to procedure mapping 

The following Physical layer (PHL) service to procedure mapping shall apply. 

Table 7: PHL service to procedure mapping 



Service 


Procedure 


Reference 


Status 


PT 


FT 


ULE1-P.1 GFSK modulation 




5.1.1 


M 


M 


GFSK modulation 


8.1.1 


M 


M 


IVIodulation scheme 1a 


8.1.2 


M 


M 


ULE1-P.2 Physical Packet P32 




5.5.1 


M 


M 


Physical Packet P32 


8.2.1 


M 


M 


Use of Physical Packet P32 


8.2.2 


M 


M 


ULE1-P.3 Physical Packet POO 




5.5.1 


M 


M 


Physical Packet POO 


8.2.3 


M 


M 


Transmission and use of Physical Packet 
POO 


8.2.4 








Reception of Physical Packet POO 


8.2.5 


M 


M 


ULE1-P.4 General PHL 




5.5.1 


M 


M 


General radio requirements 


8.3.1 


M 


M 


Radio receiver sensitivity 


8.3.2 


M 


M 


Z-field 


8.3.3 


M 


M 


Sliding collision detection 


8.3.4 


M 


M 


Physical channel availability 


8.3.5 


M 


M 


Synchronization window 


8.3.6 


M 


M 


ULE1-P.5 ULE Transmitted Power 




5.5.1 


M 


M 


IVIinimum Normal Transmit Power (NTP) 


8.3.7 


M 


M 


ULE Transmitted Power management 


8.3.8 








ULE1-P.6 Fast hopping radio 




5.5.1 








Fast hopping radio 


8.3.9 


M 


M 










NOTE: The reference column refers to the relevant clause in the present document except otherwise noted. 



6.5 MAC layer requirements 
6.5.1 MAC layer services 

DECT Ultra Low Energy, phase 1 devices shall support the following MAC layer services. 

Table 8: MAC service support 



Item 


Name of service 


Reference 


Support status 


PT 


FT 


ULE1-M.1 


General 


5.1.2 


M 


M 


ULE1-M.2 


A-field Continuous broadcast 


5.1.2 


M 


M 


ULE1-M.3 


A-field Paging broadcast 


5.1.2 


M 


M 


ULE1-M.4 


B-field Continuous ULE broadcast 


5.1.2 


M 


M 


ULE1-M.5 


B-field paging broadcast 


5.1.2 


M 


M 
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Itam 




Name of service 


Reference 


Support status 




PT 


FT 


ULE1-M.6 


Basic connection control 


5.1.2 


M 


M 


ULE1-M.7 


A-field advanced connection control 


5.1.2 


M 


M 


ULE1-M.8 


Expedited operations (advanced 
connection control) 


5.1.2 


M 


M 


ULE1-M.9 


Full slot 


5.1.2 


M 


M 


ULE1-M.10 


Short slot 


5.1.2 


M 


M 


ULE1-M.11 


lpQP_error_correction MAC service 
type 


5.1.2 


M 


M 


ULE1-M 


12 


Gp^ channel 


5.1.2 


M 


M 


ULE1-M 


13 


Cg higher layer signalling 


5.1.2 


M 


M 


ULE1-M 


14 


Cp higher layer signalling 


5.1.2 








ULE1-M 


15 


Quality control 


5.1.2 


M 


M 


ULE1-M 


16 


ULE Physical channel selection 


5.1.2 


M 


M 


ULE1-M 


17 


SARI support 


5.1.2 


M 





ULE1-M 


18 


ULE Bearer replacement (intra-cell) 


5.1.2 


M 


M 


ULE1-M 


19 


Dummy Bearer replacement 


5.1.2 


M 


M 


ULE1-M 


20 


Bearer handover inter-cell 


5.1.2 


1 


1 


ULE1-M 


21 


Connection handover 


5.1.2 


1 


1 


ULE1-M 


22 


Encryption activation 


5.1.2 


M 


M 


ULE1-M 


23 


Encryption deactivation 


5.1.2 


C801 


C801 


ULE1-M 


24 


Re-keying 


5.1.2 


C802 


C802 


ULE1-M 


25 


Early encryption 


5.1.2 


C803 


C803 


ULE1-M 


26 


DSC encryption 


5.1.2 


M 


M 


ULE1-M 


27 


AES/DSC2 encryption 


5.1.2 








C801 : IF ULE1-N.15 or ULE1-N.16 then M else 1. 

C802: IF NWK layer procedure "Re-keying during a call " THEN M ELSE 1. 

C803: IF NWK layer procedure "Early encryption " THEN M ELSE 1. 


NOTE 1 : The reference column refers to the relevant clause in the present document. 
NOTE 2: See also the DLC service ULE1-D.12 (CCM/AES encryption). 



6.5.2 MAC service to procedure mapping 

The following MAC layer service to procedure mapping shall apply. 

Table 9: MAC service to procedure mapping 



Service 


Procedure 


Reference 


Status 1 


PT 


FT 


ULE1-M.1 General 




5.1.2 


M 


M 


Frame and Multiframe structure 


10.1.1 


M 


M 


Bit mappings 


10.1.2 


M 


M 


E/U mux modes and B-field 
identification (BA) bits 


10.1.3 


M 


M 


Scrambling 


10.1.4 


M 


M 


Error control 


10.1.5 


M 


M 


RFP idle receiver scan sequence 


10.1.6 


M 


M 


Identities 


10.1.7 


M 


M 


A-field Multiplexer (T-MUX) 


10.2.1 


M 


M 


B-field control Multiplexer (E/U-MUX), 
basic modes 


10.2.2.1 


M 


M 


B-field control Multiplexer (E/U-MUX), 
Cf modes 


10.2.2.2 








ULE1-IVI.2 A-field Continuous 
broadcast 




5.1.2 


M 


M 


Downlink broadcast (A-field) 


10.3 


M 


M 


Qt - static system information 


10.3.2.1 


M 


M 


Qt - FP capabilities 


10.3.2.2 


M 


M 


Reception of downlink broadcast (A- 
field) 


10.3.3 


M 


M 


Higher layer information FP broadcast 


12.3.2 


M 


M 
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Service 


Procedure 


Reference 


Status 


PT 


FT 


ULE1-M.3 A-field Paging broadcast 




5.1.2 


M 


M 


Paging messages on A-field 


10.4.1 


M 


M 


MAC layer information messages 
procedures 


10.4.2 


M 


M 


LCE paging procedure 


10.4.3.1 








MAC layer information in zero and 
short length paging messages 


10.4.1.4 


M 


M 


ULE1-M.4 B-field Continuous ULE 
broadcast 




5.1.2 


M 


M 


Ng channel 


10.5.1 


M 


M 


Qq channel 


10.5.2 


M 


M 


Mu channel 


10.5.3 


M 


M 


Reception of Messages 


10.5.4 


M 


M 


Operation in unlocked mode 


10.5.5 


C900 


N/A 


ULE1-IVI.5 B-field Paging broadcast 




5.1.2 


M 


M 


P(j Paging Message Formats 


10.6.1 


C900 


M 


Paging Descriptors for ULE Paging 


10.6.2 


C900 


M 


ULE1-IVI.6 Basic connection control 




5.1.2 


M 


M 


Logical connection setup - procedure 
for ancillary connections 


10.7.1.2 


M 


M 


Logical connection release - 
procedure for ancillary connections 


10.7.2.2 


M 


M 


Setup of basic connection, basic 
bearer setup (A-field) 


10.4 [9] 


M 


M 


Connection/bearer release (Mj) 


10.5 [9] 


M 


M 


Bearer handover request (basic) 


10.6 [9] 


M 


M 


Connection handover request (basic) 


10.7 [9] 


M 





ULE1-M.7 A-field Advanced 
connection control 




5.1.2 


M 


M 


Logical connection setup - explicit 
procedure 


10.7.1.1 








Logical connection setup - implicit 
procedure 


10.7.1.3 


M 


M 


Logical connection release - explicit 
procedure 


10.7.2.1 








Logical connection release - implicit 
procedure 


10.7.2.3 


M 


M 


Logical connection release - abnormal 
procedure 


10.7.2.4 


M 


M 


Connection Suspend and Resume 


10.7.3 


M 


M 


Connection modification to change 
MAC service type 


10.7.4.2.1 








Connection modification to change 
slot type 


10.7.4.2.2 


1 


1 


Connection modification to change 
maximum MAC packet lifetime 


10.7.4.2.3 








Connection modification to change the 
modulation scheme and adaptive 
code rate 


10.7.4.2.4 


1 


1 


Use of ATTRIBUTES_T.req/cfm in 
connection modification 


10.7.4.2.5 


C901 


C901 


PT initiated A-field advanced bearer 
setup (Mj) 


10.9.2 


C902 


C902 


Connection/bearer release (Mj) 


10.9.3 


C903 


C903 


A-field bearer handover request 
(advanced) 


10.9.4 








A-field connection handover request 
(advanced) 


10.9.5 


1 


1 
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Service 


Procedure 


Reference 


Status 


PT 


FT 


ULE1-M.8 

Expedited operations (advanced 

connection control) 




5.1.2 


M 


M 


General 


10.10.1 


M 


M 


IVIt advanced control messages for 
expedited operations - Supported Mt 
messages 


10.10.2.1 


M 


M 


I\/1t advanced control messages for 
expedited operations - Gp^ 

transmission 


10.10.2.2 


M 


M 


IVIt advanced control messages for 
expedited operations - Reason codes 
in "expedited release" and "ready for 
release" messages 


10.10.2.3 


M 


M 


Mt advanced control messages for 
expedited operations - Operation 
codes in "Null or Gp^^channel 
transmission" message 


10.10.2.4 


M 


M 


Expedited procedures - Procedure for 
Single-burst setup and release 


10.10.3.1 


M 


M 


Expedited procedures - Procedure for 
Multi burst setup 


10.10.3.2 


M 


M 


Expedited procedures - 
Announcement "Ready for Release" 


10.10.3.3 


M 


M 


Expedited procedures - General 
Expedited Release procedure 


10.10.3.4 


M 


M 


Expedited procedures - Single- 
message expedited release procedure 


10.10.3.5 


M 


M 


Expedited procedures - Abnormal 
expedited release procedure 


10.10.3.6 


M 


M 


Use cases - General Use cases 


10.10.4.1 


M 


M 


Use cases - G-plane related use 
cases 


10.10.4.2 








Use cases - Stay alive related use 
cases 


10.10.4.3 


M 


M 


Use cases - Failure and 
Retransmission Use cases 


10.10.4.4 


M 


M 


Use cases - Data transfer use cases 
showing the response to the BGK bit 
and to transitions between BA codes 


10.10.4.5 


M 


M 


Use of reason code "normal bearer 
release" 


10.10.5.1 


M 


M 


Use of reason code "base station 
busy" 


10.10.5.2 








Use of reason code "unacceptable 
PMID/ Unregistered PIVIID" 


10.10.5.3 


M 


M 


Use of reason code "switch to circuit 
mode" 


10.10.5.4 


M 


M 


Use of reason code "Stay in LCE 
paging detection mode" 


10.10.5.5 


M 


M 


Use of reason code "Stay in higher 
paging detection mode" 


10.10.5.6 


M 


M 


Use of reason code "Setup again after 
n frames" 


10.10.5.7 


M 


M 


Use of reason code "No such 
connection / virtual circuit" 


10.10.5.8 


M 


M 


ULE-M.9 Full slot 




5.1.2 


M 


M 


D-field mapping for the full slot 
structure (physical packet P32) 


6.2.1.1.2 [3] 


M 


M 


B-field mapping for the full slot 
structure (physical packet P32) 


6.2.1.3.1.2 [3] 


M 


M 


Use of full slot in C/0 bearers 


10.11.1.1 


M 


M 


Use of full slot in C/L dummy bearers 


10.11.1.2 


M 


M 



£75/ 



42 



ETSI TS 102 939-1 V1.1.1 (2013-04) 



Service 


Procedure 


Reference 


Status 


PT 


FT 


ULE-M.10 Short slot 




5.1.2 


M 


M 


D-field mapping for the short slot 
structure (physical packet POO) 


6.2.1.1.3 [3] 


M 


M 


B-field mapping for the short slot 
structure (physical packet POO) 


6.2.1.3.1.3 [3] 


M 


M 


Use (transmission) of short slot in C/0 
bearers 


10.11.2 








Reception of short slot in C/0 bearers 


10.11.2 


M 


M 


ULE-M.11 IpQperrorcorrection MAC 
service type 




5.1.2 


M 


M 


Type 4: lp_ errorcorrection 
symmetric IVIAC service 


5.6.2.1 [3] 


M 


M 


Single-subfield protected B-field 


6.2.1.3.4 [3] 


M 


M 


MOD-2 protected channel operation 


10.8.2 [31 


M 


M 


Protected 1 channel error_correct 
mode 


10.12.1 


M 


M 


Lifetime management with TWO 
separate maximum MAC packet 
lifetimes 


10.12.2 


M 


M 


ULE1-M.12GpA channel 






M 


M 


Gp^ channel transmission 


10.13.1 


M 


M 


GpA channel data reception 


10.13.2 


M 


M 


ULE1-M.13 Cg higher layer signalling 




5.1.2 


M 


M 


Cg channel data 


10.14.1 


M 


M 


ULE1-I\/I.14 Cp higher layer signalling 




5.1.2 








Cp channel data 


10.14.2 


M 


M 


Priority schema of the Cp channel 


10.14.2.1 


M 


M 


B-field control Multiplexer (E/U-MUX), 
Cp modes 


10.2.2.2 


M 


M 


ULE1-M.15 Quality control 




5.1.2 


M 


M 


RFPI handshake 


10.8.1.1 


M 


M 


PT frequency correction procedure 


10.8.1.2 








Bearer quality report 


10.8.1.3 


M 


M 


A-CRC handshake 


10.8.1.4 


M 


M 


ULE1-M.16 ULE Physical channel 
selection 




5.1.2 


M 


M 


Channel selection for the ULE packet 
data connection 


10.8.2.1 


M 


M 


Overall architecture 


9.2.1 


M 


M 


Process MO (RFP side pre-selection 
process) 


9.2.2 


M 


M 


Broadcast mechanism 


9.2.3 


M 


M 


Process Ml (PP side channel 
selection process) 


9.2.4 


M 


M 


Setup attempt and evaluation of 
responses 


9.2.5 


M 


M 


Process M2 (collision 
handling/collision avoidance process) 


9.2.6 


M 


M 


Exceptional cases 


10.8.2.2 


M 


M 


Channel selection for the Service Call 
and other circuit mode connections 


10.8.2.3 


M 


M 


ULE1-M.17 SARI support 




5.1.2 


M 





Downlink broadcast 


10.3.2.3 


M 


M 


ULE1-M.18 ULE Bearer replacement 
(intra-cell) 




5.1.2 


M 


M 


A-field MAC Bearer replacement 
procedure (Mj) 


10.8.3 


M 


M 


A-field bearer handover request (Mj 
advanced) 


10.9.4 
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Cnrwin/^ 


Procedure 


Reference 


Status 




PT 


FT 


ULE1-M.19 ULE Dummy Bearer 
replacement 




5.1.2 


M 


M 


Dummy bearer replacement 
procedure 


10.8.4 


M 


M 


ULE1-M.20 Bearer handover inter-cell 




5.1.2 


1 


1 


A-field bearer handover request 


10.9.4 


1 


1 


ULE1-M.21 Connection handover 




5.1.2 


1 


1 


A-field connection handover request 


10.9.5 


1 


1 


ULE1-M.22 Encryption activation 




5.1.2 


M 


M 


Encryption process - initialization and 
synchronization 


10.15.1 


M 


M 


Encryption mode control; General 


10.15.2.1 


M 


M 


Encryption mode control; Mj message 


10.15.2.2 


M 


M 


Procedure for enabling encryption 


10.15.2.3 


M 


M 


Encryption activation in resume 
operations 


10.15.2.5 


M 


M 


Encryption handover control 


10.15.3 


M 


M 


ULE1-M.23 Encryption deactivation 




5.1.2 


C801 


C801 


Encryption mode control; General 


10.15.2.1 


M 


M 


Encryption mode control; Mj message 


10.15.2.2 


M 


M 


Procedure for disabling encryption 


10.15.2.4 


M 


M 


ULE1-M.24 Re-keying 




5.1.2 


C802 


C802 


Re-keying 


10.16.1 


M 


M 


ULE1-IVI.25 Early encryption 




5.1.2 


C803 


C803 


Early encryption 


10.16.2 


M 


M 


ULE1-IVI.26 DSC encryption 




5.1.2 


M 


M 


DSC encryption 


10.16.3 


M 


M 


ULE1-M.27 AES/DSC2 encryption 




5.1.2 








AES/DSC2 encryption 


10.16.4 


M 


M 


C801 
C802 
C803 
C900 
C901 

C902 
C903 


IF ULE1-N.15 or ULE1-N.16 then M else 1. 

IF NWK layer procedure "Re-keying during a call " THEN M ELSE 1. 

IF NWK layer procedure "Early encryption " THEN M ELSE 1. 

Status given in table 4 of clause 6.3. 

IF procedures "Connection modification to change MAC service type" OR "Connection modification 

to change slot type" OR "Connection modification to change maximum MAC packet lifetime" THEN 

M ELSE 0. 

IF procedure "Logical connection setup - general procedure " THEN M ELSE 0. 

IF procedure "Logical connection release - explicit procedure" THEN M ELSE 0. 


NOTE: The reference column refers to the relevant clause in the present or in the referenced document. 



6.6 DLC layer 

6.6.1 DLC layer services 

DECT Ultra Low Energy, phase 1 devices shall support the following DLC services. 
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Table 10: DLC service status 





Status 1 


Item no. 


Name of service 


Reference 


PT 


FT 


ULE1-D.1 


LU14 Enhanced Frame RELay service with CCM 
(EFREL-CCM) 


5.1.3 


M 


M 


ULE1-D.2 


LU13 Enhanced Frame RELay service with CRC 
(EFREL-CRC) 


5.1.3 








ULE1-D.3 


LU10 Enhanced Frame RELay service (EFREL) 


5.1.3 


M 


M 


ULE1-D.4 


FU10a 


5.1.3 


M 


M 


ULE1-D.5 


FU10d 


5.1.3 


M 


M 


ULE1-D.6 


Data Link Service (LAPC + Lc) class A service 


5.1.3 


M 


M 


ULE1-D.7 


DLC Transmission Class 1 


5.1.3 


M 


M 


ULE1-D.8 


Lc Frame delimiting and sequencing service 


5.1.3 


M 


M 


ULE1-D.9 


Broadcast Lb service 


5.1.3 








ULE1-D.10 


Encryption activation 


5.1.3 


M 


M 


ULE1-D.11 


Encryption deactivation 


5.1.3 


C1001 


CI 001 


ULE1-D.12 


CCIVI/AES encryption 


5.1.3 


M 


M 


C1001: IF feature ULE1-N.15 (Encryption deactivation FT initiated ) OR ULE1-N.14 (Encryption deactivation PT 
initiated) THEN M ELSE 1. 


NOTE: Tine reference column refers to the relevant clause in the present document. 



6.6.2 DLC service to procedure mapping 

The following DLC layer service to procedure mapping shall apply. 

Table 1 1 : DLC service to procedure mapping 



Service 


Procedure 


Reference 


Status 1 


PT 


FT 


ULE1-D.1 LU14 Enhanced Frame 
RELay service with CCM (EFREL- 
CCM) 




5.1.3 


M 


M 


LU14 Enhanced Frame RELay service with 
CCM (EFREL-CCM) 


11.1 


M 


M 


ULE1-D.2 LU13 Enhanced Frame 
RELay service with CRC (EFREL- 
CRC) 




5.1.3 








LU13 Enhanced Frame RELay service with 
CRC (EFREL-CRC) 


11.8 


M 


M 


ULE1-D.3 LU10 Enhanced Frame 
RELay service (EFREL) 




5.1.3 


M 


M 


LU10 Enhanced Frame RELay service 
(EFREL) 


11.2 


M 


M 


ULE1-D.4FU10a 




5.1.3 


M 


M 


FU1 Oa frame operation 


11.3.1 


M 


M 


ULE1-D.5FU10d 




5.1.3 


M 


M 


FU10d frame operation: general 


11.3.2.1 


M 


M 


Transport of FU1 Od frames over Gp^ 
channel 


11.3.2.2 


M 


M 


Insertion in FU10a frames of the opposite 
link 


11.3.2.3 








ULE1-D.6 Data Linl< Service 
(LAPC -1- Lc) class A service 




5.1.3 


M 


M 


Class A link establishment 


11.4.1 


M 


M 


Class A acknowledged information transfer 


11.4.2 


M 


M 


Class A link release 


11.4.3 


M 


M 


Class A link re-establishment 


11.4.4 


M 


M 


Handling of NWK layer messages longer 
than 63 octets 


11.4.5 








ULE1-D.7 DLC Transmission 
Class 1 




5.1.3 


M 


M 


General 


11.5.1.1 


M 


M 


Sending side procedure 


11.5.1.2 


M 


M 


Receiving side procedure 


11.5.1.3 


M 


M 
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Service 


Procedure 


Reference 


Status 


PT 


FT 


ULE1-D.8 Lc Frame delimiting and 
sequencing service 




5.1.3 


M 


M 


Cg channel fragmentation and 
recombination 


11.6.1 


M 


M 


Cp channel fragmentation and 
recombination 


11.6.2 


C1101 


C1101 


Selection of logical channels (Cg and Cp) 


11.6.3 


C1101 


C1101 


ULE1-D.9 Broadcast Lb service 




5.1.3 








Normal operation 


11.7.1 


M 


M 


ULE1-D.10 Encryption activation 




5.1.3 


M 


M 


MAC encryption switching 


11.9.1 


M 


M 


CCIVI encryption switching 


11.9.2 


M 


M 


ULE1-D.11 Encryption 
deactivation 




5.1.3 


CI 001 


C1001 


Encryption switching 


11.9 


M 


M 


ULE1-D.12 CCM/AES encryption 




5.1.3 


M 


M 


CCIVI Authenticated Encryption 


11.10.1 


M 


M 


CCM activation at Virtual Call setup 


11.10.2 


M 


M 


Cipher keys for CCIVI 


11.10.3 


M 


M 


C1001 : IF feature ULE1-N. 15 (Encryption deactivation FT initiated ) OR ULE1-N.14 (Encryption deactivation PT 

initiated) THEN M ELSE \. 
C1101 : IF ULE1-M.14 (Cp higher layer signalling) THEN M ELSE \. 


NOTE: The reference column refers to the relevant clause in the present or in the referenced document. 



6.7 NWK layer 



6.7.1 General 

The NWK layer provisions shall include the following entities: 

• Call Control (CC). 

• Mobility Management (MM). 

• Link Control Entity (LCE). 

• ConnectionLess Message Service (CLMS). 
DECT ULE phase 1 requires a NWK layer. 

6.7.2 NWK features 

DECT Ultra Low Energy, phase 1 devices shall support the following NWK layer features. 

Table 12: NWK features status 



Feature supported 


Features 


Status 1 


Item no. 


Name of feature 


Reference 


PT 


FT 


ULE1-N.1 


ULE phase 1 NWK control 


5.1.4 


M 


M 


ULE1-N.2 


ULE Service Call 


5.1.4 


M 


M 


ULE1-N.3 


Authentication of PP 


5.1.4 


M 


M 


ULE1-N.4 


Authentication of user 


5.1.4 








ULE1-N.5 


Location registration 


5.1.4 


M 


M 


ULE1-N.6 


On air key allocation 


5.1.4 


M 


M 


ULE1-N.7 


Identification of PP 


5.1.4 


M 





ULE1-N.8 


Service class indication/assignment 


5.1.4 


M 





ULE1-N.9 


Encryption activation FT initiated 


5.1.4 


M 


M 


ULE1-N.10 


Subscription registration procedure on-air 


5.1.4 


M 


M 


ULE1-N.11 


Link control 


5.1.4 


M 


M 
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Feature supported 


Features 


Status 1 


Item no. 


Name of feature 


Reference 


PT 


FT 


ULE1-N.12 


Terminate access rights FT initiated 


5.1.4 


M 





ULE1-N.13 


Authentication of FT 


5.1.4 








ULE1-N.14 


Encryption activation PT initiated 


5.1.4 








ULE1-N.15 


Encryption deactivation FT initiated 


5.1.4 








ULE1-N.16 


Encryption deactivation PT initiated 


5.1.4 








ULE1-N.17 


Enhanced security 


5.1.4 


M 


M 


ULE1-N.18 


AES/DSAA2 authentication 


5.1.4 


C1201 


C1201 


C1 201 : IF MAC service ULE1 -M.27 THEN M ELSE 0. 


NOTE: The reference column refers to the relevant clause in the present document. 



6.7.3 NWK features to procedures mapping 

The following NWK layer feature to procedure mapping shall apply. 

Table 13: NWK feature to procedure mapping 



Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 










R/B 




ULE1-N.1 ULE phase 1 NWK 
control 




5.1.4 


M 


M 




General pre-requisites 


12.1.1 


M 


M 




Creation of the ULE PVC and states 


12.1.2 


M 


M 




Allowed CC Operations over the ULE 
transaction 


12.1.3 


M 


M 




Service Change "NWK resume" 


12.1.3.1 


M 


M 




Service Change "resume" 


12.1.3.2 


M 


M 




Service Change "other" 


12.1.3.3 


M 


M 




Allowed parameters in any service 
change operation 


12.1.3.4 


M 


M 




Default parameters 


12.1.3.5 


M 


M 




Initiating part of the Service Change 
operations 


12.1.3.6 


M 


M 




Independence of other CC transactions. 


12.1.3.7 


M 


M 




Default IVIAC parameters for implicitly 
created MBC 


12.1.3.8 


M 


M 




Paging descriptors in suspend and 
resume states 


12.1.3.9 


M 


M 




ULE1-N.2 ULE Service call 




5.1.4 


M 


M 




Service call setup 


12.2.1 


M 


M 




Normal call release 


8.7 [91 


M 


M 




Abnormal call release 


8.8 [9] 


M 


M 




Transport of IWU-to-IWU data 


13.2.1 










ULE1 -N.3 Authentication of the PP 




5.1.4 


M 


M 




Authentication of PP using DSAA 


8.24 [91 


M 


M 




Authentication of PP using DSAA2 


8.45.7 [91 


C1301 


CI 301 




Storing the Derived Cipher Key (DCK) 


8.27 [9] 


M 


M 




Storing the Derived Cipher Key for CCM 
(DCK-CCM) 


12.2.2 


M 


M 




ULE1 -N.4 Authentication of the 
user 




5.1.4 










Authentication of user using DSAA 


8.25 [9] 


M 


M 




Authentication of user using DSAA2 


8.45.8 [9] 


C1301 


CI 301 




ULE1-N.5 Location registration 




5.1.4 


M 


M 




Location registration 


8.28 [9] 


M 


M 




Location update 


8.29 [9] 


M 







Terminal Capability indication 


12.3.1 


M 


M 




ULE-N.6 On air key allocation 




5.1.4 


M 


M 




Key allocation using DSAA 


8.32 [91 


M 


M 




Key allocation using DSAA2 


8.45.9 [9] 


C1301 


CI 301 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 










R/B 




ULE1-N.7 Identification of PP 




5.1.4 


M 







Identification of PT 


8.22 [9] 


M 


M 




ULE1-N.8 Service class 
indication/assignment 




5.1.4 


M 







Obtaining access rights 


8.30 [9] 


M 


M 




Terminal Capability indication 


12.3.1 


M 


M 




Authentication of PP using DSAA 


8.24 [9] 


M 


M 




Authentication of PP using DSAA2 


8.45.7 [91 


C1301 


CI 301 




ULE1-N.9 Encryption activation FT 
initiated 




5.1.4 


M 


M 




Cipher-switching initiated by FT using 
DSC 


8.33 [9] 


M 


M 




Cipher-switching initiated by FT using 
DSC2 


8.45.10 [9] 


C1303 


CI 303 




Storing the Derived Cipher Key (DCK) 


8.27 [9] 


M 


M 














ULE1-N. 10 Subscription 
registration user procedure on-air 




5.1.4 


M 


M 




Obtaining access rights 


8.30 [91 


M 


M 




Terminal Capability indication 


12.3.1 


M 


M 




ULE1-N.11 Link control 




5.1.4 


M 


M 




Indirect FT initiated link establishment 


8.35 [9] 










Direct PT initiated link establishment 


8.36 [9] 


M 


M 




Link release "normal" 


8.37 [91 


M 


M 




Link release "abnormal" 


8.38 [91 


M 


M 




Link release "maintain" 


8.39 [91 


M 


M 




ULE1 -N.I 2 Terminate access 
rights FT initiated 




5.1.4 


M 







FT terminating access rights 


8.31 [91 


M 


M 




Authentication of FT using DSAA 


8.23 [91 





M 




Authentication of FT using DSAA2 


8.45.6 [9] 


C1302 


CI 301 




ULE1-N. 13 Authentication of FT 




5.1.4 










Authentication of FT using DSAA 


8.23 [91 


M 


M 




Authentication of FT using DSAA2 


8.45.6 [9] 


C1301 


CI 301 




ULE1-N.14 Encryption activation 
PT initiated 




5.1.4 










Cipher-switching initiated by PT using 
DSC 


8.34 [91 


M 


M 




Cipher-switching initiated by PT using 
DSC2 


8.45.11 [91 


C1303 


CI 303 




Storing the DCK 


8.27 [91 


M 


M 




ULE1 -N.I 5 Encryption 
deactivation FT initiated 




5.1.4 










Cipher-switching initiated by FT using 
DSC 


8.33 [91 


M 


M 




Cipher-switching initiated by FT using 
DSC2 


8.45.10 [91 


C1303 


CI 303 




ULE1. N.I 6 Encryption 
deactivation PT initiated 




5.1.4 










Cipher-switching initiated by PT using 
DSC 


8.34 [91 


M 


M 




Cipher-switching initiated by PT using 
DSC2 


8.45.11 [91 


C1303 


CI 303 




ULE1-N.17 Enhanced security 




5.1.4 


M 


M 




Encryption of all calls 


8.45.1 [91 


M 


M 




Re-keying during a call 


8.45.2 [9] 










Early encryption 


8.45.3 [9] 










Subscription requirements 


8.45.4 [91 


M 


M 




Behaviour against legacy devices 


8.45.5 [91 
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Feature/Procedure mapping 




Status 1 


Feature 


Procedure 


Reference 


PT 


FT 1 










R/B 




ULE1-N.18AES/DSAA2 
authentication 




5.1.4 


C1201 


CI 201 




Authentication of FT using DSAA2 (see 
note) 


8.45.6 [9] 










Authentication of PP using DSAA2 


8.45.7 [91 


M 


M 




Authentication of user using DSAA2 


8.45.8 [9] 










Key allocation using DSAA2 


8.45.9 [9] 


M 


M 




Cipher-switching initiated by FT using 
DSC2 


8.45.10 [9] 


CI 303 


CI 303 




Cipher-switching initiated by PT using 
DSC2 


8.45.11 [9] 


CI 304 


CI 304 




Storing the Derived Cipher Key (DCK) 


8.27 [9] 


M 


M 




Storing the Derived Cipher Key for CCM 
(DCK-CCM) 


12.2.2 


M 


M 




C1 201 : IF MAC service ULE1 -M.27 THEN M ELSE 0. 

C1301: IF feature ULE1-N.18 THEN M ELSE 1. 

C1302: IF feature ULE1-N.18 and THEN ELSE 1. 

C1 303 IF MAC service ULE1 -M.27 THEN M ELSE 1. 

C1 304: IF (feature ULE1 -N.1 5 or feature ULE1 -N.1 6) and MAC service ULE1 -M.27 THEN M ELSE 1. 


NOTE: The reference column refers to the relevant clause in the present or in the referenced document. 



6.8 Application Layer 
6.8.1 Application features 

DECT Ultra Low Energy, phase 1 devices shall support the following application features. 

Table 14: Application features status 



Feature supported 


Status 


Item no. 


Name of feature 


Reference 


PT 


FT 


ULE1.A.1 


AC to bitstring mapping 


5.1.5 


M 


M 


ULE1.A.2 


Multiple subscription registration 


5.1.5 





N/A 


ULE1.A.3 


Easy PIN code registration 


5.1.5 








NOTE: The reference column refers to the relevant clause in the present document. 



6.8.2 Application features to procedures mapping 

The following Application layer feature to procedure mapping shall apply. 

Table 15: Application feature to procedure mapping 



Feature/Procedure mapping 


Status 1 


Feature 


Procedure 


Ref. 


PT 


FT 


AC to bitstring mapping [ULE1.A.1] 






M 


M 


AC to bitstring mapping 


14.2 [9] 


M 


M 


Multiple subscription registration 
[ULE1.A.2] 









N/A 


Subscription control 


14.1 [9] 


M 


N/A 


Easy PIN code registration [ULE1.A.3] 












Registration mode automatic access 


7.10.1.3.1 [13] 


M 


N/A 


Searching mode and PIN code requests 


7.10.1.1.1 [13] 


M 


N/A 


Base station name selection 


7.10.1.3.2 [13] 








Registration user feedback 


7.10.1.3.3 [13] 








NOTE: The reference column refers to the relevant clause in the present or in the referenced document. 
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6.9 



Distributed communications 



The distributed communication mode (PP-PP communication) is not part of the present document. 

6.10 IVIanagement Entity (IVIE) 

6.1 0.1 IVIanagement Entity (ME) services 

In regard to ULE phase 1 equipment, the following ME services shall apply. 

Table 16: Management Entity Requirements 



Feature supported 


Status 1 


Feature 


Name of feature 


Ref. 


PT 


FT 


ULE1-ME.1 


ULE phase 1 Management 


5.1.6 


M 


M 


ULE1-ME.2 


ULE Physical Channel Selection 


5.1.6 


M 


M 


NOTE: The reference column refers to the relevant clause in the present document. 



6.1 0.2 Management Entity (ME) mode to procedures mapping 

In regard to ULE phase 1 equipment, the following ME service to procedure mapping shall apply. 
Table 17: Management Entity mode to procedures mapping 



Feature/Procedure mapping 


Status 


Service 


Procedure 


Reference 


PT 


FT 


ULE phase 1 Management [ULE1-ME.1] 




5.1.6 


M 


M 


ULE phase 1 connection and resources 
management 


9.1.1 


M 


M 


Stay alive procedure 


9.1.2 








ULE Physical Channel Selection [ULE1- 
ME.2] 




5.1.6 


M 


M 


Overall architecture of ULE channel 
selection processes 


9.2.1 


M 


M 


Process MO (RFP side pre-selection 
process) 


9.2.2 


M 


M 


Broadcast mechanism 


9.2.3 


M 


M 


Process Ml (PP side channel selection 
process) 


9.2.4 


M 


M 


Setup attempt and evaluation of responses 


9.2.5 


M 


M 


Process M2 (collision handling/collision 
avoidance process) 


9.2.6 


M 


M 


NOTE: The reference column refers to 


the relevant clause in the present document 







6.1 1 U-plane services and interworking requirements 
6.1 1 .1 U-plane and interworking services 

DECT Ultra Low Energy, phase 1 devices shall support the following U-plane and interworking services. 

Table 18: U-plane services and interworking 



Item 


Name of service 


Reference 


Support status 


PT 


FT 


ULE1-I.1 


Transparent U-plane Interworking 


5.1.7 


M 


M 


NOTE: The reference column refers to the relevant clause in the present document. 
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6. 11 .2 U-plane and interworking service to procedure mapping 

The following U-plane and interworking service to procedure mapping shall apply. 

Table 19: U-plane and interworking service to procedure mapping 



Service 


Procedure 


Reference 


Status 


PT 


FT 


ULE1-I.1 Transparent U-plane 
Interworking 




5.1.2 


M 


M 


U-plane procedures 


B.2.1 


M 


M 


C-plane procedures 


B.2.2 


M 


M 


Transport of IWU-to-IWU data 


13.2.1 








NOTE: The reference column refers to the relevant clause in the present document. 



7 



Profile specific procedures description 



All profile specific procedures are described in clauses 8 to 13 of the present document, organized by layers. 

This clause may be used for the definition of general profile specific procedures or general requirements in further 
releases of the present document. 



8 



Physical Layer (PHL) procedures 



8.1 Supported Modulation types and schemes 

8.1.1 GFSK modulation 

All equipment compliant with the present document shall support GFSK modulation, as defined by EN 300 175-2 [2], 
clause 5.4. 

8.1 .2 Modulation scheme la 

All equipment compliant with the present document shall support the modulation scheme configuration la, as defined 
by EN 300 175-2 [2], clause 5.4 and table D.l. 

8.2 Supported Physical Packets 

8.2.1 Physical Packet P32 

All equipment compliant with the present document shall support the Physical Packet P32, as defined by 

EN 300 175-2 [2], clause 4.4.2. 

8.2.2 Use of Physical Packet P32 

All equipment compliant with the present document shall use the Physical Packet P32 for all ULE connection oriented 
services transmissions, except within the exceptions listed in clause 8.2.4, where Packet POO may be also used. 

NOTE 1: Equipment compliant with the present document may also implement other DECT applications. In such a 
case other packets may be used for non ULE services. 

All FPs compliant with the present document shall use the Physical Packet P32 for the transmission of the dummy 
bearer and shall not use Packet POO in any case. 
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The provision given in the previous paragraph shall be respected, even if the FP supports simultaneously other DECT 
non-ULE services, and even if multiple dummy bearers are temporally or permanently broadcasted. 

NOTE 2: However, it should be assumed that FPs may have mechanisms to completely deactivate the ULE 

capabilities. In such a case the device is no longer compliant with the present document and dummy 
bearer over POO may be used. 

8.2.3 Physical Packet POO 

All equipment compliant with the present document shall support the reception and may support the transmission of 
Physical Packet POO, as defined by EN 300 175-2 [2], clause 4.4.1. 

8.2.4 Transmission and use of Pinysical Pacl^et POO 

All equipment compliant with the present document may optionally use the Physical Packet POO for transmission of 
connection oriented service packets with empty B fields in the specific cases described in clause 10.11.2.2 of the present 
document "Use of short slots for packets containing "no B-field". 

All equipment compliant with the present document shall not use the Physical Packet POO in any other case. 

8.2.5 Reception of Pinysical Packet POO 

All equipment compliant with the present document shall support the reception of Physical Packet POO for connection 
oriented service packets with empty B fields in the specific cases described in clause 10.11.2.2 of the present document 
"Use of short slots in C/O bearers". 

8.3 General PHL procedures 

8.3.1 General radio requirements 

As specified in EN 300 175-2 [2] and EN 301 406 [11] (replacing TBR 006 [i.2]). 

8.3.2 Radio receiver sensitivity 

The radio receiver sensitivity shall be -86 dBm, or better. 

8.3.3 Z-field 

The Z-field shall be transmitted by RFPs and PTs. 

8.3.4 Sliding collision detection 

PT and FT shall be able to detect sliding collision on received packets. 

Minimum criteria for sliding collision are defined as S- or Z-field failure. Early sliding collision detection may be 
supported by other means e.g. signal strength measurements in the guard band. 

The Z-field is defined to have failed if the received X- and Z-fields are not identical. 

S-field failure is defined with some tolerance in order not to restrict the physical implementation of the word 
synchronization detector. 

S-field failure may be indicated if there are 1 or more bit errors in bits s 12 to s31 (errors in bits sO to s 1 1 shall be 
ignored). In all cases, S-field failure shall be indicated if 3 or more bit errors occur in bits sl6 to s31. 

When protected B-field format is used, B field CRC criteria may be used for detecting sliding collisions. 
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8.3.5 Physical channel availability 

A FP shall be able to receive and transmit on all DECT frequencies fO to f9 and at least half of the slot pairs to 11. 

A PP shall be able to receive and transmit on all DECT frequencies fO to f9, and shall be able to lock on any slot 
number to 11, and receive and transmit at least on every slot pair that is not directly neighboured to the slot the PP is 
locked to, or to a slot on which a traffic bearer is active at the PP. 

8.3.6 Synchronization window 

Related to its reference timer, the PP synchronization window shall be at least +4 bits for bearers to the RFP to which 
the reference timer is synchronized, and at least +10 bits for other bearers. 

8.3.7 Minimum Normal Transmit Power (NTP) 

The nominal NTP shall be greater than 80 mW per simultaneously active transmitter as shown by the test verdict 
criteria and declaration of EN 300 176-1 [10], clause 10.2.3. 

8.3.8 Power management 

To fight mutual interference between data terminals operating in different local DECT networks when using for the 
transmission most of the slots from a frame, control of the transmission power is recommended. 

If transmission power control procedure is implemented, the requirements in EN 300 175-2 [2], annex E shall fully 
apply. 



8.3.9 Fast hopping radio 



The radio transceiver shall be able to perform any frequency change during the interval between two consecutive 
Physical Packets P32 (full slot). 



9 Management Entity (ME) procedures 

9.1 ULE phase 1 Management 

9.1 .1 ULE phase 1 connection and resources management 

The management entity rules for the present document are based on the following elements: 

• Simplified Network Layer CC model based on PVC (Permanent Virtual Circuit) controllable by means of 
Service Change operations, as described in feature [ULEl-N.l] ULE phase 1 NWK control. 

• Use of two mechanisms of Suspend and Resume: Network layer suspend and resume, as described in 
clause 12.1, and MAC layer suspend and resume, as described in clause 10.7.3. 

• Network layer Suspend and Resume is used to control the NWK layer state of the Virtual Circuit, which may 
be changed between two states: suspended and resumed. 

• DLC link and MAC MBC are automatically created by changing the NWK layer state. This mechanism, called 
"implicit connection setup" is specific of ULE. 

• In normal operation mode (NWK resumed, link and MBC created), data can be exchanged using specific 
MAC layer procedures. MBC is preserved and remains in suspended (MAC suspended) state at the end of the 

activity. 

• Specific "expedited" MAC procedures for optimized transfer of ULE data, with minimum overhead, and ultra 
fast response time. 
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More specific ME rules may be added to fiirther releases of the present document. 



9.1 .2 Stay alive procedure 



ULE phase 1 may use a stay alive procedure, to control the integrity of the connection and the existence of the other 
peer. 

No specific stay alive procedure is defined in the present document. Therefore, the design of the stay alive procedure is 
left to the implementer. 

The expected response after a failure, or a multiple failure, of the stay alive handshake is notification to higher layers 
and release of the MBC and DLC link, moving the NWK state to "NWK suspend". 

9.2 Channel selection and collision avoidance procedures 

9.2.1 Overall architecture of ULE channel selection processes 

DECT ULE devices shall implement the Physical channel selection procedures as described in EN 300 175-3 [3], 
clause 11.12. The processes and mechanisms described in EN 300 175-3 [3], clause 11.12.2 shall be implemented. 

9.2.2 Process IVIO (RFP side pre-selection process) 

DECT ULE RFPs shall implement the process MO (RFP side pre-selection process) as described in EN 300 175-3 [3], 
clause 11.12.3. 

Implementation at PP side shall consist in the understanding of the RFP algorithm. 

The guidelines given in EN 300 175-3 [3], clause 11.12.3 shall be followed. 

The following additional provisions shall apply: 

• The value of m is m = 2. 

• In order to compile the list of candidate channels, the RFP shall routinely scan all DECT channels (except 
those impossible to receive by physical limitations) and compute their RSSI. 

• In order to consider a given channel as candidate for setup, both simplex bearers of it shall be measured in at 
least one frame, and the worst (highest) RSSI value shall be used. 

The following additional guidelines are given: 

• Due to the need to have the RFP receiver listening for possible setups according to the scan sequence, for 
single transceiver systems, it is assumed that the scan of the uplink simplex bearer will be done, in practice, 
listening to the scan sequence frequency. 

• The scan of the downlink bearers of the channels may be done with the same criteria (listening according to 
RFP scan sequence), or with a different cycle (implementation choice). 

• The measurement of the RSSI should be done assuming that the slot to be used on the transmission will be a 
fall slot. 

• Other mechanisms, such as multi-transceiver RFP are possible. 

• As general rule, the unnecessary restriction of the offered channels by reserving fixed slots for other services is 
not recommended. 

A possible implementation of algorithm MO is provided in clause C. 1 . 
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9.2.3 Broadcast mechanism 

DECT ULE RFPs shall implement and DECT ULE PPs shall understand the broadcast mechanism described in 

EN 300 175-3 [3], clause 11.12.4. 

The following additional provisions shall apply: 

• The value of m, the time difference between frame that carries the broadcast and the access frame for which 
the channel selection information refers, shall be equal to 2. Therefore all channel selection information shall 
refer to frame N+2. 

9.2.4 Process M1 (PP side cinannel selection process) 

DECT ULE PPs shall implement the process Ml (PP side channel selection process) as described in EN 300 175-3 [3], 
clause 11.12.5. 

Implementation at REP side shall consist in the understanding of the PP setup process. 

The following additional provisions and notes shall apply: 

• For PPs without power consumption limitations (fast actuators) higher numbers of n may be used. 

• It is allowed to receive and decode the content of channel selection information in the dummy bearer in frames 
Nh-1 or Nh-2, in order to quickly react to the event of repetition of algorithm Ml due to no validation of any 
candidate channel. 

• PP devices without power consumption limitations (fast actuators) may be continuously scanning the dummy 
bearer channel selection info and continuously performing the RSSI validation in order to be ready for a fast 
response to an event (paging or PP side event) requiring setup. 

• The measurement of the RSSI shall be done taken into account the slot type that will be used in the 
transmission. 

9.2.5 Setup attempt and evaluation of responses 

PPs shall perform the access request and evaluation or responses as defined in EN 300 175-3 [3], clause 1 1. 12.6. 
Implementation at REP side shall consist in the understanding of the PP response. 
The following additional provisions shall apply: 

• The differentiation of error responses compatible and not compatible with collision is optional. If this 
differentiation is not implemented all error cases shall be followed by execution of algorithm M2. 

• In case or impossibility of access due to repetitive lack of channels in the information provided by the base, or 
impossibility to validate the channels provided, the PP is allowed to perform a regular DECT scan and use 
regular DECT channel selection mechanisms. 

9.2.6 Process M2 (collision handling/collision avoidance process) 

DECT ULE PPs shall implement the process M2 (PP side collision handling/collision avoidance process) as described 
in EN 300 175-3 [3], clause 11.12.7. 

Implementation at REP side shall consist in the understanding of the PP response under potential collision conditions. 

The following additional provisions and notes shall apply: 

• The value of the parameter b in the equation A of 1 1 .12.7. 1 shall be as defined in clause A. 1 . 1 . 1 of the present 
document. 

NOTE: All other parameters of the equations are defined by EN 300 175-3 [3], clause A.2. 1 . 
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1 MAC layer procedures 

10.1 General 

1 0.1 .1 Frame and multiframe structure 

The FT and PT shall support frame and multiframe structures as defined in EN 300 175-3 [3], clause 4.2. 



10.1.2 Bit mappings 



The FT and PT shall support the D-field mappings as defined in EN 300 175-3 [3], clause 6.2.1.1 for full slot, Physical 
Packet P32, GFSK modulation and modulation schema la (clause 6.4.1, table 5 and clause 6.4.2 table 6). 

The FT and PT shall support the D-field mappings as defined in EN 300 175-3 [3], clause 6.2.1.1 for short slot. Physical 
Packet POO, GFSK modulation and modulation schema la (clause 6.4.1, table 5 and clause 6.4.2 table 6). 

The FT and PT shall support the A-field mappings as defined in EN 300 175-3 [3], clause 6.2.1.2 for the supported 
Physical Packets (clause 6.4.1 table 5) and modulation schema (clause 6.4.2, table 6). 

The FT and PT shall support the B-field mappings as defined in EN 300 175-3 [3], clause 6.2.1.3 for the supported 
Physical Packets (clause 6.4.1 table 5) modulation and modulation schema (clause 6.4.2, table 6) and for the E/U mux 
modes described in clause 10.1.3. 

1 0.1 .3 E/U mux modes and B-field identification (BA) bits 

NOTE: See also clause 10.2.2 for detailed provisions regarding the E/U multiplexer modes. 

10.1 .3.1 E/U mux modes and B-field identification (BA) bits for C/0 bearers 

The FT and PT shall support the following E/U mux modes and associated B-field identifications (BA bits a4, a5 and 
a6) as defined in EN 300 175-3 [3], clause 7.1.4 for traffic C/O bearers: 

• BA = "000"B: U-type, Ip packet number 0; 

• BA = "001"B: U-type, Ip packet number 1; 

• BA = "1 H"B: no B-field, (shall only be used for connection oriented bearers); 

• BA = " 1 10"B: E-type, all MAC control. 

The Ipp channel should not be used in ULE connections. 

The FT and PT may optionally support the following E/U mux additional modes and associated B-field identifications 
(BA bits a4, a5 and a6) as defined in EN 300 175-3 [3], clause 7.1.4 for traffic C/O bearers: 

• BA = "010"B: E-type, all Cp, packet number 0; 

• BA = "01 1"B: E-type, all Cp, packet number 1; 

• BA = " 100"B: E-type, not all Cp, packet number 0; 

• BA = "101"B: E-type, not all Cp, packet number 1. 
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10.1 .3.2 E/U mux modes and B-field identification (BA) bits for C/L (dummy) bearers 

The FT and PT shall support the following E/U mux modes and associated B-field identifications (BA bits a4, a5 and 
a6) as defined in EN 300 175-3 [3], clause 7.1.4 for dummy C/L bearers: 

• BA = " 1 10"B: E-type, all MAC control. 

10.1.4 Scrambling 

The FT and PT shall support scrambling as defined in EN 300 175-3 [3], clause 6.2.4. 

The dummy C/L bearer containing the special B-field ULE dummy structure shall not be scrambled. 

The previous provision applies even if there are several ULE dummy bearers. 

Other C/L bearers not containing the special B-field ULE dummy structure, if used, shall be normally scrambled as 
defined in EN 300 175-3 [3], clause 6.2.4. 

10.1.5 Error control 

The FT and PT shall support R-CRC and X-CRC generation as defined in EN 300 175-3 [3], clause 6.2.5. 
FT and PT shall support 16-Bit R-CRC as defined in EN 300 175-3 [3], clause 6.2.5.2. 

1 0.1 .6 RFP idle receiver scan sequence 

The FT shall support primary scan as defined in EN 300 175-3 [3], clause 11.8. 

10.1.7 Identities 

The provisions of EN 300 175-3 [3], clause 1 1 .7 and EN 300 175-6 [6] shall be implemented with respect to the 
structure and use of identities. 

10.2 Time multiplexers 

10.2.1 A-field IVIultiplexer 

1 0.2.1 .1 Tail Multiplexer (T-MUX) 

The FT and PT shall support T-MUX as defined in EN 300 175-3 [3], clause 6.2.2.1. 
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10.2.1.2 A-tail identifications 



The FT and PT shall understand all A-field tail identifications (bits aQ to a2) as defined in EN 300 175-3 [3], 
clause 7.1.2. The value 101 - "escape" need not be understood. To distinguish a connectionless bearer from a 
non-connectionless bearer the Nj message send on a connectionless bearer shall carry the value "Identity information 

(Nj) on connectionless bearer" (010) and the value "Identity information (Nj)"(01 1) in all other cases. 

1 0.2.2 B-field control Multiplexer (E/U-MUX) 

1 0.2.2.1 B-field control Multiplexer (E/U-MUX), basic modes 

1 0.2.2.1 .1 U-type Multiplexer for C/0 bearers 

The FT and PT shall support the following U-type multiplexer modes as defined in EN 300 175-3 [3], clause 6.2.2.2 for 
traffic C/O bearers: 

• BA = "000"B: U-type, Ip packet number 0; 

• BA = "001"B: U-type, Ip packet number 1. 

1 0.2.2.1 .2 E-type Multiplexer "all MAC control" for C/O bearers 

The FT and PT shall support the following E-type multiplexer mode as defined in EN 300 175-3 [3], clauses 6.2.2.2 and 
6.2.2.3: 

• BA = " 1 10"B: E-type, all MAC control. 
The following restrictions apply: 

• Channel Gp does not need to be supported. 

• MAC control messages for controlling channel Ipp do not need to be supported. 

The FT and PT shall support the E-type mode "all MAC control" as defined in EN 300 175-3 [3], clause 6.2.2.3 
(tables 6.24 to 6.33) for the supported D-field mappings (defined in clause 6.2, table 1 1) and modulation type (defined 
in clause 5.1, table 7). 

10.2.2.1.3 E-type Multiplexer "no-B field" for C/O bearers 

The FT and PT shall support the following E-type multiplexer mode as defined in EN 300 175-3 [3], clauses 6.2.2.2 and 
6.2.2.3: 

• BA="111"B: no B-field 

NOTE: This BA code and mux mode should only be used over C/O bearers. 

In general, the B A coding and multiplexer mode "no-B field" shall be understood as transmission of an unprotected 
filling pattern over the B-field (format similar to MAC service Cp. However, in some specific cases (and only in them) 
it is allowed the transmission of a short slot instead (optional, transmission choice). Such cases are described in 
clause 10.11 .2.2. ULE Receivers shall be aware of such optional behaviour. 

1 0.2.2.1 .4 E-type Multiplexer "all MAC control" for C/L (dummy) bearers 

The FT and PT shall support the following E-type multiplexer mode as defined in EN 300 175-3 [3], clauses 6.2.2.2 and 
6.2.2.3, over dummy C/L bearers: 

• BA = " 1 10"B: E-type, all MAC control. 
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The following restrictions apply: 

• The repertory of possible MAC control messages is reduced according to the C/L type of the bearer. 

• Channel Gp does not need to be supported. 

• MAC control messages for controlling channel Ipp do not need to be supported. 

In ULE RFPs, the use of "no B-field" mode and the use of short slots over dummy bearers is not allowed. 

The FT and PT shall support the E-type mode "all MAC control" as defined in EN 300 175-3 [3], clause 6.2.2.3 
(tables 6.24 to 6.33) for the supported D-field mappings (defined in clause 6.2, table 1 1) and modulation type (defined 
in clause 5.1, table 7). 

10.2.2.1.5 E/U-Mux priority schema 

The FT and PT shall support the priority schema as defined in EN 300 175-3 [3], clause 6.2.2.4 with the following 
restrictions: 

• Ipp channel modes and Ipp segmentation control are not applicable. 

• Cp channel modes are not applicable. 

1 0.2.2.1 .6 B-field identifications (basic) 

The FT and PT shall use and understand all B-field identifications (bits a^ to ag) as defined in EN 300 175-3 [3], 
clause 7. 1 .4 with the following restrictions: 

• Codes for E-mux with Cp channel ("010", "Oil", 100" and "101") are not applicable. 

• Code "110" is only understood as "E-type all MAC control". 

• Code " 1 1 1" is only understood as "no B-field". 

1 0.2.2.2 B-field control Multiplexer (E/U-MUX), Cf modes 
1 0.2.2.2.1 E-type Multiplexer, all modes (over C/0 bearers) 

The FT and PT shall support E-type mode multiplexer as defined in EN 300 175-3 [3], clauses 6.2.2.2 and 6.2.2.3, 
including the modes "E-type all Cp", and "E-type not all Cp" over traffic C/O bearers. 

The FT and PT shall support all E-type modes as defined in EN 300 175-3 [3], clause 6.2.2.3 (tables 6.24 to 6.33) for 
the supported D-field mappings (defined in clause 6.2, table 1 1) and modulation type (defined in clause 5.1, table 7). 

The following modes shall be supported: 

• BA = "010"B: E-type, all Cp packet number 0; 

• BA = "01 1"B: E-type, all Cp, packet number 1; 

• BA = " 100"B: E-type, not all Cp packet number 0; 

• BA = "lOr'B: E-type, not all Cp packet number 1. 

NOTE: It is not allowed the transmission of Cp over the dummy bearer. 



£75/ 



59 ETSI TS 1 02 939-1 V1 .1 .1 (201 3-04) 



1 0.2.2.2.2 E/U-Mux priority schema 



The FT and PT shall support the priority schema as defined in EN 300 175-3 [3], clause 6.2.2.4 with the following 
restriction: 

• Ipp channel modes and Ipp segmentation control are not applicable. 

1 0.2.2.2.3 B-field identifications (Cf) 

The FT and PT shall use and understand all B-field identifications (bits a^ to ag) as defined in EN 300 175-3 [3], 
clause 7.1.4 with the following restrictions: 

• Code "110" is only understood as "E-type all MAC control". 

• Code "111" is only understood as "no B-field". 

1 0.3 Downlink broadcast (A-field) 

The procedure shall be performed as defined in EN 300 444 (GAP) [9], clause 10.2 and EN 300 175-3 [3], clause 9.1.1. 

10.3.1 Nt messages 

The same message defined in EN 300 444 (GAP) [9], clause 10.2.1 shall be used. 

10.3.2 Qt messages 

1 0.3.2.1 Qt - static system information 

The FT shall be capable of sending and the PT shall be capable of receiving and processing the Qj static system 
information message as defined in EN 300 175-3 [3], clause 7.2.3.2, with the following contents as defined below. 

The same contents defined in EN 300 444 (GAP) [9], clause 10.2.3 shall be supported. 

1 0.3.2.2 Qt - FP capabilities 

1 0.3.2.2.1 Standard FP Capabilities 

The FP shall indicate its standard capabilities using the fixed part capabilities Qj message as described in 

EN 300 175-3 [3], clause 7.2.3.4, with contents as defined below. The PT shall be able to receive and understand this 

message. 
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Table 20: Values used within Standard FP capabilities 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


« FP capabilities » 








<0h> 


3 




<ai2> 


1 


Extended FP info (0^ = 4) 


<ai5> 


[0,1] 


Double slot (optional) 


<ai7> 


1 


Full slot (mandatory to support) 


<a23> 


1 


Basic A-field setup, mandatory 


<a24> 


[0,1] 


Advanced A-field setup. See note 1 (optional) 


<a26> 


[0,1] 


Cp messages, if PT supports only Cg 
messages it may ignore this value. 


<a30> 


1 


lp_error_correction (mandatory to support) 








NOTE 1 : The bit < 834 > sliall only be set if the messages for A-field advanced bearer setup (Mj) and release are 

supported. Refer to clauses 1 0.9.2 and 1 0.9.3. It shall not be set if only the implicit connection setup and 
release as described in clause 10.9.6 is supported. 
NOTE 2: For the higher layer capabilities, bits < 833 to a^j >, see clause 12.3.2.1.1. 



The MAC extended fixed part information message shall be used and, therefore, bit a22 of the fixed part information 
field shall be set to 1 . 

Higher layer information: The management entity in the FP supplies the MAC layer with a 16-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits < a32> to < cl^']> of the Qt message. At the 

PT the MAC layer passes the 16 bits out through the ME SAP to the management entity. 
For the setting of the higher layer information bits see clause 12.3.2.1.1. 



10.3.2.2.2 



Extended FP Capabilities 



The FP shall indicate its extended capabilities using the Extended fixed part capabilities Qj message as described in 
EN 300 175-3 [3], clause 7.2.3.5, with contents as defined below. The PT shall be able to receive and understand this 

message. 

Table 21 : Values used within Extended FP capabilities 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


« FP capabilities » 










<0h> 


4 














<a22> 


1 


IpQ services supported. 




<a23> 


1 


Extended FP capabilities Part 2. 


NOTE: For the higher layer capabilities, , bits < aggto 847 >, see clause 12.3.2.1.2. 



The MAC extended fixed part capability part 2, information message shall be used and, therefore, bit a23 of the 
extended FP capability field shall be set to 1 . 

Higher layer information: The management entity in the FP supplies the MAC layer with a 23-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits <a25> to <a47> of the Qt message. At the PT 
the MAC layer passes the 24 bits out through the ME SAP to the management entity. 

For the setting of the higher layer information bits see clause 12.3.2.1.2. 
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10.3.2.2.3 



Extended FP Capabilities part 2 



The use of Extended FP Capabilities part 2 is needed in all cases due to the position of the bit <a39> in the Extended 
higher layer capabilities broadcast, which defines the support of ULE phase 1 (see clause 12.3.2.1.3). All bits in the 
MAC layer part of the broadcast are optional and will be set to describe the support of optional features, or services 
other than ULE. Due to the probable coexistence with NG-DECT services in the same RFP, it should be assumed that 
most RFPs will broadcast some of them. 

The FP shall indicate its extended capabilities using the Extended fixed part capabilities part 2 Qj message as described 
in EN 300 175-3 [3], clause 7.2.3. 11, with contents as defined below. The PT shall be able to receive and understand 
this message. 

Table 22: Values used within Extended FP capabilities part 2 



MAC message 


Field within the 
message 


Standard values within 
the lUIAC message 


Normative action/comment 


« FP capabilities » 








<Qh> 


C (hex) 




<ai2> 


[0,1] 


Long slot support (j = 640). 








NOTE: For the higher layer capabilities, bits <a24to a^j >, see clause 12.3.2.1.3. 



Higher layer information: The management entity in the FP supplies the MAC layer with a 24-bit SDU via the 
Management Entity (ME) SAP. The content of that SDU is placed in bits <a24> to <a47> of the Qt message. At the PT 
the MAC layer passes the 24 bits out through the ME SAP to the management entity. 

For the setting of the higher layer information bits see clause 12.3.2.1.3. 

1 0.3.2.3 Qt - SARI list contents 

The FT may send and the PT shall be capable of receiving and processing (if broadcast by the FT) the Qj SARI 

message as defined in EN 300 175-3 [3], clause 7.2.3.6, with same contents as defined by EN 300 444 (GAP) [9], 
clause 10.2.4. 

This is relevant if the N j message indicates SARI support. 

10.3.2.4 Multiframe number (A-field) 

Qj message carries the multiframe number which is used in the encryption algorithm. Both, FT and PT, shall be able to 
transmit and respectively retrieve the information carried in this message. 

Table 23: Values used within Qy multiframe number message 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


« multiframe number » 








< Q header > 


6 




< spare > 


111100001111 B 




< multi frame number > 


All 


The number of the multiframe, 
modulo 2**24. 



1 0.3.3 Reception of downlink broadcast (A-field) 

DECT ULE PPs are not required to listen to downlink broadcast channels (over A-field) in all states. They will listen to 
these channels only in specific situations. 

The following channels are considered downlink broadcasts for this description: 

• N^ : Identities Information 
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• Qj : Static System Information 

• Q^ : FP capabilities 

• Qj : SARI contents 

Specifically, ULE PPs shall listen to downlink broadcasts in the following cases: 

• During initial registration process. 

• During the VC setup process. 

• PPs supporting at the same time DECT voice services (GAP or NG-DECT) shall listen to the Q-p broadcast as 
required by such profiles. 

NOTE: In general, ULE PPs will not be listening to downlink broadcasts channels in regular operation, idle state 
(registered, idle locked or unlocked -depending on the type of PP- and with a suspended VC opened 
towards a RFP). 



10.4 Paging broadcast 



This clause refers to the LCE paging capability using A-field messages. Refer to clause 10.6 for ULE paging using B- 
field channels. 

1 0.4.1 Paging message formats 

The FT and PT shall support full, short and zero length paging message formats as defined in EN 300 175-3 [3], 
clause 7.2.4. 

1 0.4.1 .1 Full page message format 

Table 24: Values used within full-page message format 



MAC message 


Field within the message 


Standard values 

within the MAC 

message 


Normative action/comment 


« Pj full page format » 








< Pj-header extend flag > 
Os) 


0,1 


ag = 1 means another page 

message shall start in the next 
frame in this multiframe that is 
permitted to contain a Pj type. 


< BS SDL) length indication > 
(agtoaii) 


010 


Full-page message shall be 
used to carry LCE resume page 
message. 


< BS channel data > 
(ai2toa47) 


All 


The content of the BS channel 
data is defined by the 
LCE-message definition. 



10.4.1.2 Short page message format 

The same values defined in EN 300 444 GAP) [9], clause 10.3.1 shall be supported. 

1 0.4.1 .3 Zero length page message format 

The same values defined in EN 300 444 GAP) [9], clause 10.3.2 shall be supported. 
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10.4.1 .4 MAC layer information in zero and short length paging messages 

The following MAC layer information types defined by EN 300 175-3 [3], clause 7.2.4.3 shall be supported 
(understood) by a PT. 

Table 25: Types of MAC layer paging information to be supported by a PT 



^32 


^33 


^34 


^35 


MAC information type 











1 


Blind slot information for circuit mode service. 








1 





Other bearer. 








1 


1 


Recommended other bearer. 





1 





1 


Dummy or C/L bearer position. 


1 








1 


Bearer handover/replacement information. 


1 





1 





RFP-status and Modulation Types (see clause 10.4.1.4.1). (The IVIodulation 
Types replaces the spare bits.) 


1 


1 








C/L bearer position 


1 


1 


1 


1 


Blind slot information for packet mode service. (This replaces the 
Modulation Types information.) 



10.4.1.4.1 



RFP status 



RFP 
Status 


Modulation Types 


A-field 


(B + Z)-fields 


^36 




^39 


^40 ^43 


844 847 



Figures: RFP status 



Table 26: RFP status 



RFP status 


Meaning 


Oxxx 


RFP clear for data. 


1xxx 


RFP busy for data (see note). 


NOTE: "RFP busy for data" means that the RFP recommends PTs not to send access 
request messages for ULE service towards this RFP. 



Bits a4Q to a43 define the modulation schemes supported in the A-field, in addition to the default one. Since no other A- 
field modulation schemas are used in the present document, the listening and understanding of the flags is irrelevant. 
They shall be coded by the transmitter as shown in table 27. 

Table 27: RFP status A-field modulation scheme 



^40 


341 


342 


^43 


A-field modulation scfieme 














Only 2-level modulation supported. 



Bits a44 to a^-j define the modulation schemes supported in the (B + Z)-fields, in addition to the default one. All HLM 

modes in B-field are for further study and are not used by the current revision of the present document. However they 
may be added in future revisions or used by other services implemented in the RFP. All RFPs implementing the present 
document shall support at least the 2-level modulation and shall code the bit a^-j accordingly. This is shown in table 28. 

Table 28: RFP status B+Z field modulation scheme (mandatory coding for all types of RFP 

implementing the present document) 



844 


845 


346 


847 


(B + Z)-fields modulation scheme 


X 


X 


X 


1 


2-level modulation supported. 



For the usual case of RFP supporting only the present document, or the present document plus other 2-level modulation 
service, the coding of the bits shall be as shown in table 29. 
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Table 29: RFP status B+Z field modulation scheme (coding for RFP supporting only 2-level 

modulation services) 



344 


^45 


^46 


^47 


(B + Z)-fields modulation scheme 


1 


1 


1 


1 


only 2-level modulation supported. 



1 0.4.2 MAC layer information messages procedures 

The following MAC layer information message procedures are defined as described below. Each supported message 
shall be broadcasted at least once every 10 s. 

In regard to the support status of the different codes, the provisions of EN 300 444 [9], clause 10.3.1 shall apply. 

10.4.2.1 Blind slot information for circuit mode service 

The provisions of EN 300 444 (GAP) [9], clause 10.3.3 shall apply. 

10.4.2.2 Bearer handover/replacement information 

The provisions of EN 300 444 (GAP) [9], clause 10.3.4 shall apply. 

1 0.4.2.3 Other bearer position 

The RFP is recommended to broadcast the "other bearer" information indicating the position of a 2"'^ dummy bearer or 
traffic bearer, if such bearer exists. 

1 0.4.2.4 Recommended other bearer position 

The RFP is recommended to broadcast the "recommended other bearer" information indicating the position of another 
bearer. This message shall not be sent unless the bearer that it is sent on will be released in less than or equal to 
4 multiframes. 

1 0.4.2.5 Dummy or C/L bearer position 

The RFP shall announce the dummy bearer position, if a dummy bearer exists. 

1 0.4.2.6 C/L bearer position 

The RFP shall announce the connectionless downlink bearer position, if such a bearer exists. The bearer position shall 
be announced 1 Multi -Frame (4 MF in case of low duty cycle) in advance of transmission of C/L data via this bearer. 

1 0.4.2.7 RFP-status and Modulation Types 

The RFP should send the RFP-status information "RFP busy-for-data/not-busy-for-data" as soon as possible after a 
detection of a change in RFP-status, i.e. in the first allowed frame after the change. It is recommended that the RFP 
periodically sends the RFP-status information. It is not recommended to send this message very often when the status 
changes frequently, because the other messages may be delayed too long. A practical limit may be to send this 
information not more than once a second. 

RFPs which are capable of Higher Layer Modulation shall transmit this message to announce this capability, otherwise 
the peer will assume that only default modulation is available. For the present document, this is 2-level modulation. 

1 0.4.2.8 Blind slot information for packet mode service 

The RFP shall announce the slots which are blocked for packet mode service. The coding of the message is identical to 
clause 10.4.2.1 Blind slot information for circuit mode service, except that the MAC layer information type bits are 
coded as 'llll'B('OF'H). 
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ULE PPs shall use this information for ULE mode setups. 

The same provisions and procedure given by EN 300 444 (GAP) [9], clause 10.3.3 for the voice service shall be 
followed, but applied to the ULE service. 

10.4.3 Paging Procedures 
10.4.3.1 LCE Paging 

The procedure shall be performed as defined by EN 300 175-3 [3], clauses 9.1.3.1 and 9.1.3.2.2. 
This procedure includes transmission and reception of Zero length, short and full page messages. 
In the LCE procedure, the Bg channel SDU is provided by the DLC layer. 
The procedure is compatible with normal, high and low duty cycle paging detection modes in the PT. 

10.4.4 Paging detection 

1 0.4.4.1 Normal duty cycle 

The procedure shall be performed as defined by EN 300 175-3 [3], clause 9.1.3.2.1. 

The PT shall be in the state "Normal Idle Locked mode" as defined in EN 300 175-3 [3], clause 11.3.3.1. In this mode, 
the PT shall receive any Bg channel transmitted in frame and additional frames that are commanded by the extend 

flag. 

The normal duty cycle detection state applies to LCE paging procedures. 

10.5 ULE Dummy Bearer Procedures 

The following procedures shall be performed as defined in EN 300 175-3 [3], clause 9.5. 

10.5.1 Ns channel 

The FT shall send the Ng message in all frames where a ULE Dummy Bearer is active and the PT shall be capable of 
receiving and processing the Ng split identities message as defined in EN 300 175-3 [3], clause 7.3.5. 

This message contains the RFPI of the RFP constructed in an identical manner to the information sent in an Nj message 
as defined in EN 300 175-3 [3], clause 7.2.2 but in this message it is separated into two fields as defined in 
EN 300 175-3 [3], clause 9.5. 

10.5.2 Qc channel 

The FT shall send the Qq message in all frames where a ULE Dummy Bearer is active and the PT shall be capable of 
receiving and processing the Q^ compound system information message as defined in EN 300 175-3 [3], clause 7.3.5. 

This message contains information constructed in an identical manner to the information sent in Qj messages. 
Specifically the SN and PSCN fields as in QO messages, see EN 300 175-3 [3], clause 7.2.3.2 and the multiframe 
number as in Q6 messages, see EN 300 175-3 [3], clause 7.2.3.7. In addition this message also contains frame number, 
preamble pattern and ULE Dummy Bearer specific synchronization pattern as defined in EN 300 175-3 [3], clause 9.5. 

10.5.3 Mu channel 

The FT shall send one My message in every frame where a ULE Dummy Bearer is active and the PT shall be capable 
of receiving and processing the M^j ULE MAC control channel message as defined in EN 300 175-3 [3], clause 7.3.5. 
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The message contains MAC layer information specific to ULE devices and shall be as defined in EN 300 175-3 [3], 
clause 9.5. 



1 0.5.4 Reception of Messages 



DECT ULE PTs are not required to listen for Ng, Q^- or My messages at any mandated rate, the PTs will listen when 
there is a requirement for the PT to gain lock to a specific FT at which point the Ng, Qq and M^ messages shall be 
collected and the information understood to enable the PT to lock to the desired FT. 

All the information necessary to allow a PT to lock to the desired FT is contained in the Ng, Qq and M^ messages 
included in a single slot transmission so they may all be collected in a single reception. 



10.5.5 Operation in unlocked mode 

Operation in unlocked mode refers to the operation mode when the PP losses the locked state to the REP during idle 

time. 

The PP shall be capable to get synchronization again to the RFP, when required, by using the information provided in 
the channels Ng and Qq. 

The PP shall be capable to react properly to a possible change in slot and/or carrier of the dummy bearer during the 
inactivity time. 

The exact re-synchronization algorithm is left to the implementer. 

10.6 ULE Paging Procedures 

This clause refers to ULE specific paging capability using B-Field channels over the ULE dummy bearer. Refer to 
clause 10.4 for LCE paging using A-field tail. 

10.6.1 Pu Paging Message Formats 

The FT and PT shall support the ULE Dummy Bearer paging format as defined in EN 300 175-3 [3], clause 7.3.5. The 
FT shall send a P^ message in all frames where a ULE Dummy Bearer is active and the PT shall be capable of 
receiving and processing the P^j ULE Paging channel message. 

The message contains information specific to ULE devices and shall be as defined in EN 300 175-3 [3], clause 9.5. 



1 0.6.1 .1 Pu Message General format 

The Pjj Message is spread across two fields of the ULE Dummy Bearer, one field of 44 bits and one field of 56 bits as 
shown below, the 44 bit field is subdivided into a control field (comprised of the SFa, SFTj and CA mask fields) and a 
data field, the 56 bit field is solely a data field. 



44 bit field 



Control 

SFa/SFb 

/CA 



'^104 '^m 



Subfield a Data 
Field 



'112 



"143 



56 bit field 


Subfield b Data Field 


^248 


'^SOS 



Figure 6: General Pg message format 
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Table 30: Subfield A Data Field Meaning 



SFa 


Associated data b^^g^o'^us 


bl04 


bl05 








No information 





1 


32 bits of B,j data as a page 


1 





32 bits of B,j data as a broadcast 


1 


1 


Reserved 



Table 31 : Subfield B Data Field Meaning 



SFb 


Associated data b^^2*°''i43 


^106 


bl07 








No information 





1 


56 bits of B,j data as a page 


1 





56 bits of B,j data as a broadcast 


1 


1 


Reserved 



Table 32: CA Field Meaning 



CA 


IVIeaning 


''lOS 


''log 


•^no 


^111 










4 bits of Bj data as a bit masl< 



Unlike LCE paging the data sent in the P^ message has no fixed meaning for the ULE PT, the higher layers 
communicate the meaning of the data in their negotiation of capabilities of the system using the « ULE-MAC- 
CONFIGURATION-INFO » information element as defined in the present document, clause A. 2. 1 . The B^ data 

received in the P^ message is passed to the higher layers for processing. Simple examples of the operation of this 
mechanism are shown in the present document, clause C.2. 

1 0.6.2 Paging Descriptors for ULE Paging 

The ULE Dummy Bearer paging channels (B^ channel and P^ channel) are used to pass transient information from the 
FT to the PT. As described in the present document, clause 10.6.1.1 the meaning of the information passed is given to 
the PTs by the FT using the « ULE-MAC-CONFIGURATION-INFO » information element in higher layer 
messages passed to each specific PT. 

The « ULE-MAC-CONFIGURATION-INFO » information element enables the FT to describe how messages in the 
paging channel (B^ and P^j channels) should be understood by the PT to which the information element has been sent. 
This information is passed from the FT to the PT using channel descriptors within the information element. 

When this information element is sent from the FT to the PT it can indicate that any new descriptors shall be added to 
existing descriptors, that have already been sent, or it can indicate that all descriptors sent earlier should be deleted and 
replaced with any subsequent descriptors. This is handled with the Control field. 

Each channel descriptor consists of 5 octets that describe an individual channel in terms of its intended use, how often it 
is sent, when it is sent in terms of frames, a mask to indicate certain channels are in use and a data field. There are no 
specific numbers/names given to each channel, how they are referenced is determined by the higher layers. 

The intended use of each channel is indicated by the channel descriptor type. For phase 1, there are two types of 
descriptors: a page type and a broadcast type. The page type is expected to be used to indicate that particular PTs should 
attempt to setup a link with the FT, and the broadcast type is expected to be used to pass information to PTs. In the 
descriptor for the page type the data passed indicates in the BitOffset field which bit(s) shall be used by the PT as a 
mask for the BitOffset field of any page message received to start the receiving PT to setup a link with the FT. In the 
descriptor for the broadcast type the BitOffset field is empty. The channel periodicity, frame and multiframe fields 
indicate how often messages shall be sent in this channel and what frame they start in, this enables each PT to ensure it 
listens to the relevant channels. 
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The channel active mask field allows the FT to indicate to specific PTs that there is a message that is relevant to the 
specific PT being sent. If the mask sent in the channel active field of a channel descriptor has any bits matching the 
channel active mask field sent in any paging channel message the PT shall listen to the next possible message sent on 
that channel. 

For simple examples of the usage of this mechanism, see clause C.2.1 of the present document. 

10.7 Connection Management 
10.7.1 Logical Connection Setup 

Logical Connection Setup is the procedure of creation of MBC. Depending on the procedure, it may be immediately 
followed by a Physical connection setup or not. 

10.7.1 .1 ULE logical connection setup - explicit procedure 

The creation of an MBC shall be performed as described in EN 300 175-3 [3], clause 10.2.4. 1, with the following 
specific provisions: 

• Connection shall be advanced, full slot; 

• ECN number shall be set to "7". 

The connections created with this ECN shall be "Expedited" as defined in EN 300 175-3 [3], clause 10.2.5. 

Initial Physical Connection setup as immediate result of the creation of the MBC shall be performed as described in 
clause 10.9.2. Subsequent Physical Connection setup (resume) shall be performed using expedited procedures (see 
clause 10.10). 

1 0.7.1 .2 ULE logical connection setup - procedure for ancillary connections 

The creation of an MBC for an ancillary connection, such as the required by the feature [ULE1-N.2] (Service Call) is 
done as described in EN 300 175-3 [3], clause 10.2.4, with the following specific provisions: 

• Connection shall be basic, full slot. 

Therefore the procedure is identical to the one used in GAP (EN 300 444 [9]). 

The ancillary connection is not controllable by means of "Expedited" operations as defined in EN 300 175-3 [3], 
clause 10.2.5 and in clause 10.10 of the present document. 

1 0.7.1 .3 ULE logical connection setup - implicit procedure 

It is possible to create a pair of MBCs for the ULE connection without any exchange of air interface messages by means 
of the mechanism described in clause 12.1.3.1.2.2, case b). In order to do that, another MBC, generally associated to a 
circuit mode service, should exist in order to transport the NWK layer messages. This mechanism is called implicit 
creation of the MBC pair. After an implicit creation of the MBCs, the procedure is not necessarily immediately 
followed by a Physical connection setup. 



10.7.2 Logical Connection Release 



Logical Connection Release is the procedure of removal of an MBC. This procedure is preceded by either a NWK layer 
release procedure, by a NWK layer suspend procedure or by a handshake failure. 

The NWK layer release procedure and the NWK layer suspend procedure will cause DLC layer to send a MAC_DIS- 
req primitive to MBC (and also the clearing of the DLC U-plane and C-plane instances as well). 

The stay alive procedure may also cause the ME to send a MAC_DIS-req primitive to MBC. 

Logical connection release will also cause a Physical Connection release, if the connection is active. 



£75/ 



69 ETSI TS 1 02 939-1 V1 .1 .1 (201 3-04) 

The following procedures are possible. 

10.7.2.1 ULE logical connection release - explicit procedure 

The following procedure shall be performed: 

• If the connection was active, the procedure A-field connection/bearer release as defined in clause 10.9.3 shall 
be executed. 

NOTE: It is assumed that a NWK layer RELEASE procedure has been previously executed between both peers in 
order to release the logical connection. 

• If the connection was suspended, releasing explicitly the logical connection requires resuming the connection, 
executing the NWK layer RELEASE procedure, and then executing the A-field connection/bearer release as 
defined in clause 10.9.3. 

10.7.2.2 ULE logical connection release - procedure for ancillary connections 

This procedure shall be used to release the MBC for an ancillary basic connection, such as the required by the feature 
[ULE1-N.2] (Service Call). 

The same procedure described in EN 300 444 (GAP) [9], clause 10.5 shall be performed. The procedure releases at the 
same time the bearer and the connection. 

NOTE: An ancillary connection does not support MAC suspend/resume. Therefore, its MBC may only be in 

active state. 

10.7.2.3 ULE logical connection release - implicit procedure 

The execution of the NWK layer procedure "NWK suspend" as described in clause 12. 1 .3.2, when the NWK messages 
are carried by a different MBC to the one associated to the CC entity, and when the associated MBC is in "MAC 
suspend" state, causes the release of the MBC at both peers without any further signalling operation. 

This procedure is called "logical connection release - implicit procedure" and is the connection release normally used in 
ULE. 

The NWK layer procedure is described in clause 12.1.3.2. The implicit release procedure is the case a) described in 
clause 12.1.3.2.3.2. 

10.7.2.4 ULE logical connection release - abnormal procedure 

Abnormal release of the connection at all levels may also be done by the Management Entity as result of failure of stay- 
alive procedures. In such a case, the procedure is implicit and there is no exchange of air i/f messages. 

10.7.3 Connection Suspend and Resume 
10.7.3.1 General 

The suspend/resume process used in ULE in entirely handled at MAC layer and under control by the Management 
Entity in response to instantaneous traffic need. The suspend/resume process is the DECT packet handling mechanism 
over the MAC C/O service. 

The suspend/resume process happens at an imaginary in between the MAC TBC (also called lower-MAC) and the 
MAC MBC (also called higher-MAC). This applies to both U-plane and C-plane transmissions. 

MBC and higher layers are active and, in general, not aware of the suspend/resume state. However they may contribute 
to trigger the suspend/resume process by sending traffic (U-plane or C-plane) to the lower layers, which would be 
detected by the Management Entity and would trigger the proper action at MAC layer. 

Packet handling Suspend/resume process is part of the MAC C/O service. 
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10.7.3.2 Suspend 



Suspend is defined as the process of releasing the physical connection without releasing the logical connection. 
Therefore in suspend state: 

• There are not physical bearers active at the physical layer 

• There is not active TBC entity 

• There is a MBC associated to the connection 

• All higher layer entities (DLC and above) associated to the connection are active, and, in general are not aware 
of the suspend state at lower MAC layer 

10.7.3.2.1 Entering in suspended state 

A connection enters in suspend state by releasing its bearer at MAC layer without an explicit process of connection 
release. 

The previous principle applies independently of the process for the bearer release, that may be normal (as described in 
clause 10.9), expedited (as describe in clause 10.10) or even due to errors, abnormal operations or timeouts. 

An ULE connection also enters in suspends state (and shall not be completely released) by abnormal loss of the bearer. 

NOTE: In this case, the stay-alive procedure (see clause 9.1.2) will be in charge of debugging the situation. 

The explicit process of connection release is normally done by a NWK layer procedure. In this revision of the present 
document the procedure is the NWK layer Service Change "suspend" (see clause 12.1.3.2). This procedure moves the 
NWK state to "NWK suspend" (see clause 12.1.2) and releases the MBC (MAC connection). 

The ME handshake procedure (see clause 9.1.2) may also release the MAC connection. 

10.7.3.3 Resume 

Resume is the process of activating the physical layer for an existing connection in suspended state. 

A connection is resumed state behaves as a normal DECT connection and includes at least a TBC entity. However the 
connection is still identified as packet-mode at MBC level, which would trigger the proper action at MBC level (pass to 
suspend state) after the release of the bearer and TBC. 

The provisions of EN 300 175-3 [3], clause 10.3.1.1 shall apply. 
1 0.7.3.3.1 Resuming a suspended connection 

For devices compliant with the present document the resume process is performed by executing a bearer setup process 
with any of the following two options: 

• Any Advanced connection setup (as described in clause 10.9) with the ECN number belonging to an existing 
suspended connection between the PT - FT pair. 

NOTE 1 : Therefore any setup process with a different ECN should be understood as the setup of a separate 
connection (if supported). 

• Any expedited bearer setup as described in clause 10. 10.3 of the present document. 

Expedited bearer setups (any) shall be understood as a resume process to an existing connection with 
ECN = 7. 

NOTE 2: Therefore expedited operations cannot be used for initial setup, or when there is no a suspended 
connection. 

All devices compliant with the present document shall use the ECN = 7 for the DECT ULE service and shall not reuse 
such value for any other service. Expedited operations shall be used only for controlling the ULE connection. 
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NOTE 3: However, it is possible to have other DECT services (voice or data) over the same FT - PT pair with 
different ECN values. 

NOTE 4: It is also possible to have other packet mode services over the same FT - PT pair, however they should be 
handled with regular advanced connection control messages (clause 10.9) and not with expedited 
messages (clause 10.10). 

10.7.3.3.1.1 FT initiated resume 

Resuming a connection from the FT side shall be performed using indirect setup via B-field paging. For ULE PPs, a 
dedicated paging channel inside the B-field of the dummy bearer(s) is used for triggering the resume process from FT 
side (indirect setup). See clause 10.6 for description of the B-field resume paging procedures. 

10.7.4 Other Connection Modification 

The following additional connection modification procedures (other than suspend and resume) may be supported by 
ULE devices. 

10.7.4.1 Void 

10.7.4.2 Connection modification to change service type, slot type, modulation type or 
adaptive code rate 

1 0.7.4.2.1 Connection modification to change MAC service type 

The MAC connection modification procedure to change the service type is needed to change the actual service type of a 
logical connection to a new one due to the result of the NWK service negotiation defined by clause 12.5 or service 
changes defined in clauses 12.6 and 12.7. 

The connection modification procedure to change the service type between the following service types defined by 
EN 300 175-3 [3], clauses 5.6.2.1 and 5.6.2.2: 

• Ip]y[_error_correct; 

• IpQ_error_correct. 

The connection modification procedure to change the service type is only needed, if other MAC service types than 
IpQ-6rror_correct are supported. 

The connection modification procedure to change the service type shall be performed as defined by EN 300 175-3 [3], 
clause 10.3.2.1. The attributes_request and attributes _confirm message exchanged for this procedure shall be the 
ATTRIBUTES_T.req/cfm message as defined by EN 300 175-3 [3], clause 7.2.5.3.8. 

The connection modification to change service type shall be only performed following a NWK layer Service Change 
negotiation. 

1 0.7.4.2.2 Connection modification to change slot type 

The MAC connection modification procedure to change the slot type is needed to change the slot type of a logical 
connection to a new one due to the result of the NWK service negotiation defined by clause 12.5 or service changes 
defined in clauses 12.6 and 12.7. 

The connection modification procedure is in charge to change the slot type between the following slot types defined by 
EN 300 175-3 [3], clause 6.2.1.1: 

• Full slot (physical packet P32); 

• Double slot (physical packet P80); 

• Long slot (physical packet P64); 
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Long slot (physical packet P67). 



The connection modification procedure to change the slot type is optional to support, and has only sense if multiple 
MAC slots supported. 

The connection modification procedure to change the slot type shall be performed as defined by EN 300 175-3 [3], 
clause 10.3.2. The attributes_request and attributes_confirm message exchanged for this procedure shall be the 
ATTRIBUTES_T.req/cfm message as defined by EN 300 175-3 [3], clause 7.2.5.3.8. 

The connection modification to change slot type shall be only performed following a NWK layer Service Change 
negotiation to change slot (see clause 12.6.2). 

10.7.4.2.3 Connection modification to change maximum MAC packet lifetime 

The MAC connection modification procedure to change the maximum MAC packet lifetime is needed to change this 
parameter which influences the Ip_error_correct operation. The following provisions shall apply: 

The connection modification procedure to change the maximum MAC packet lifetime shall be performed as defined by 
EN 300 175-3 [3], clause 10.3.2. The attributes_request and attributes_confirm message exchanged for this procedure 
shall be the ATTRIBUTES_T.req/cfm message as defined by EN 300 175-3 [3], clause 7.2.5.3.8. 

In general, there is no need for a NWK layer service negotiation to change the MAC maximum MAC packet lifetime. 

The value provided by the FT shall apply. 

1 0.7.4.2.4 Connection modification to change the modulation scheme and adaptive code 
rate 

The use of HLM or encoded protected MAC service in DECT ULE is for further study. 

1 0.7.4.2.5 Use of ATTRIBUTES_T.req/cfm in connection modification 

This clause applies to all connection modification cases covered by clause 10.8.2. 

The ATTRIBUTES_T.req/cfm message as defined by EN 300 175-3 [3], clause 7.2.5.3.8 shall be used for connection 
modification to change service type and/or modulation scheme. 

The message shall be supported if any connection modification case covered by clause 10.7.2 has to be implemented. 

The following fields as defined in EN 300 175-3 [3], clause 7.2.5.3.8 of the ATTRIBUTES_T.req/cfm messages shall 
be supported by the PT and the FT. 
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Table 33: Values used within ATTRIBUTES_T.req/cfm messages 



MAC message 


Field within the message 


Standard values 

within the MAC 

message 


Normative action/comment 


« Mj message » 








< IVIj header > 


0001 


"Advanced connection control". 


< Command > 


6 


"Attributes T.request". 




7 


"Attributes T.confirm". 


<ECN> 


7 


ECN = 7 reserved for ULE 


<LBN> 


1 to 15 


Any value shall be supported. 
Value shall match the LBN of the 
bearer that carries the message. 


< up/down/ss/sm > 


"11"B 


Symmetric single bearer 
connection 


< service type > 


7 


lpQR_error_correct mandatory to 
support 


< max. lifetime > 


1 to 7 


Values 1 to 7 mandatory to support 


< slot type > 


0, 2, 3, 4 


Full slot (code = 'O'B) mandatory to 
support. Double, long 640 and long 
672 slots optional. 


<Cp> 


[0,1] 


Cp support is optional 


< extended (B + Z) field 
mod. type > 





(extended (B + Z) field not used). 


< adaptive code rate > 





No coding used (see note 2). 


< A-field modulation type > 


3 


Default modulation scheme is 
2-level modulation. All others 
schemas are for further study 


< (B + Z) field mod. type > 


3 


Default modulation scheme is 
2-level modulation. All others 
schemas are for further study 
(note 1). 


NOTE 1 : Modulation fields other default modulation schema are for further study. 
NOTE 2: Use of encoded protected services and adaptive code rate is for further study. 



10.8 Other MAC control procedures 

10.8.1 Quality control 

10.8.1.1 RFPI handshake 

RFPI handshake procedure shall be performed as defined in EN 300 175-3 [3], clause 1 1.5.1. 

1 0.8.1 .2 PT frequency correction 

PT frequency correction procedure shall be performed as defined in EN 300 175-3 [3], clause 1 1.5.2.2. 

10.8.1.3 Bearer quality report 

Receiver side will send bits Ql (or BCK) and Q2 reporting quality of received bearers. Report shall be done in bits a3 
and a-j of a field in the reverse bearer of the duplex pair. 

The bit Ql shall be set as defined in EN 300 175-3 [3], clause 10.8.1.3.4. The bit Q2 shall be set as described in 

EN 300 175-3 [3], clause 10.8.1.3.3. In lp_error_correct services, the bit Q2 shall be set as defined in EN 300 175-3 [3], 

clause 10.8.2.4.1, and the bit BCK, set as defined in EN 300 175-3 [3], clause 10.8.2.4.2, shall be send in the place of 

bitQl. 

FT and PT should use the information of the received bits Q 1 and Q2 to take the decision to perform bearer replacement 
procedures. 
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FT may use the information of the Ql and Q2-bits sent by the PT, to decide whether to switch antenna or not. 

1 0.8.1 .4 A-CRC handshake 

When a TBC is in active connected state, if no correct A-CRC is received (in regard to the active FT identity) for a time 
equal to maximum MAC packet lifetime, the bearer shall be released. The abnormal expedited release procedure 
(clause 10.10.3.6) shall be used in this case. 

NOTE: The normal reaction on the release of a bearer because of A-CRC handshake failure will be setup a new 
bearer over a new TBC. 

1 0.8.2 Physical channel selection 

1 0.8.2.1 Channel selection for the ULE packet data connection 

The ULE specific channel selection mechanisms, as described in clause 9.2, shall be used for the channel selection of 
the ULE packet data connection (MBC resume procedure), except in the exceptional cases listed in clause 10.8.2.2. 
Such channel selection procedures, combined with expedited setup procedures (clause 10.10) shall be the normal 
operation procedures for all types of ULE Portable Parts. This rule applies in all cases, including PP types that may be 
continuously locked to the RFP such as PPs type II "fast actuator" [ULE1-TYP.4]. 

10.8.2.2 Exceptional cases 

Regular DECT channel selection procedures (as described in EN 300 175-5 [5], clause 1 1.4) may only be used for 
channel selection for the ULE packet data connection, on an exceptional basis, in the following cases: 

• In the initial setup of the connection, when explicit procedures are used (see clause 10.7.7.1.1). 

• When using regular advanced (non expedited) bearer setup procedure. 

• In case or impossibility of access due to repetitive lack of channels in the information provided by the base, or 
repeated impossibility to validate the channels provided by the RFP. 

10.8.2.3 Channel selection for the Service Call and other circuit mode connections 

The setup of the Service Call (feature [ULE1-N.2]), or other circuit-mode connections that may exist in the system, 
shall be done using regular DECT channel selection procedures as described in EN 300 175-5 [5], clause 1 1.4. 

1 0.8.3 A-field MAC Bearer replacement procedure (Mj) 

The PT shall be able to perform bearer replacement, by setting up new TBCs within the same logical connection. The 
following rules shall apply: 

The bearer replacement shall be always implemented by dropping the existing bearer before establishing the 
new one. 

There should not be more than one bearer over the air at any time. 

Bearer replacement shall be performed in case of transmission errors prior to achieving the expedited 
"connected" state (see present document, clause 10.10.4.1.2.3). 

Bearer replacement shall be performed at least at every SDU boundary, i.e. every new SDU submitted by the 
higher layers shall utilize a new TBC. 

Additionally, bearer replacement, at a position other than an SDU boundary, is optional, and may be supported 
by some implementations. 

This procedure only applies to ULE packet mode connections. 

The quality criteria that cause a bearer replacement are left to the implementer. 
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1 0.8.4 Dummy bearer replacement procedure 

The FT shall be able to control the quality and to move the position of the dummy bearer as response to quality issues. 
The following rules shall be followed. 

10.8.4.1 Quality control 

The FT shall be able to periodically measure the background RSSI level on the dummy bearer channel. To do that, it is 
allowed to interrupt the transmission of the dummy bearer from time to time. 

This interruption of transmission has some implications on system operation: 

• A ULE PP device might try to lock to the FP on this frame, resulting in it missing the dummy bearer 
broadcast. 

• The ULE FP is unable to broadcast any paging information in this frame. 

The detrimental effect of the above points can be mitigated somewhat by appropriate design. For example: 

• The frequency of the FP's RSSI scan can be limited. 

• The PP sync algorithm can take into account that some frames might be missing. 

• The FP can avoid allocating this frame for paging broadcast schedules. 
The details and use of any such mitigation strategies are left to the implementation. 

10.8.4.2 Requirements 

The bearer replacement shall consist of raising a new dummy bearer on a new channel, before releasing the old 
one. 

The old dummy bearer shall be released latest four multiframes after raising the new replacement dummy 
bearer. 

The number of physical channel changes for the dummy bearer shall not exceed 5 changes per any one minute 
interval (see EN 300 175-3 [3], clause 5.7). 

It is not allowed to miss transmissions in frames 0, 8 and 14 of a multiframe (see EN 300 175-3 [3], 
clause 6.2.2.1.1). 

The FP shall broadcast the position of the new dummy bearer using the A-field MAC layer information for Pt 
message, with the coding for "dummy or C/L bearer position" (see EN 300 175-3 [3], clause 7.2.4.3.4). 

Modification of frequency should be avoided if possible, for example by moving to a different slot on the same 
frequency. However, this should only occur if allowed by channel selection algorithm. 

The FP shall miss at most one downlink transmission in any one second interval. 

NOTE: EN 300 175-3 [3], clause 5.7 describes the normal procedures for dummy bearer replacement. 

10.9 A-field (Mj) Advanced Connection control procedures 
10.9.1 General 

A-field MAC advanced control procedures are used for the setup, release and handover of ULE connections. They may 
be used in any case (including initial setup, resume, suspend and complete release), however expedited operations 
(clause 10.10) are assumed to be normally used in suspend and resume by efficiency reasons. 
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The following procedures are available: 

• PT initiated A-field advanced bearer setup. 

• A-field connection/bearer release. 

• A-field bearer handover request (optional). 

• A-field connection handover request (for further study). 

1 0.9.2 PT initiated A-field advanced bearer setup 

The connection setup procedure shall be performed as defined in EN 300 175-3 [3], clauses 10.2.4.1 and 10.2.4.2 or 
10.2.4.3. 

The connection setup procedure described in EN 300 175-3 [3], clause 10.2.4.2 shall be used in the following cases: 

• PT initiated setup (all cases). 

• FT initiated indirect setup (via paging). 

The bearer setup procedure shall be performed in all cases as defined in EN 300 175-3 [3], clause 10.5.1.2. 

The exchange of the messages "Attributes_T.req" and "Attributes_T.cfm" is mandatory in all cases. The PT shall send 
the "Attributes_T.req" message after reception of the "Bearer.cfm" as described in EN 300 175-3 [3], clause 10.5.1.2.1. 

In the case of FT initiated (indirect) setup, the LCE paging code = " 1 10"B shall be used in the initial setup of the call 
and LCE = "1 H"B in the case of resume of an existing connection. 

NOTE: It is expected that the use of this procedure and the LCE = " 1 11 "B code for resume will be an infrequent 
use case since resume will be generally performed using expedited procedures (see clause 10.10). 

1 0.9.2.1 Mt access request message 

The following fields as defined in EN 300 175-3 [3], clause 7.2.5.3 of in the MAC control (Mj) message shall be 
supported by the PT and the FT. 

Table 34: Values used within IVIj message 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


«Mj message» 








<l\/lj header> 


1 


"Advanced connection control". 


<Command> 





"Access request". 




4 


"Bearer confirm". 




5 


"Wait". 




6 


"Attributes T request" (see note). 




7 


"Attributes T confirm" (see note). 


<FMID> 


All 




<PMID> 


All 


See clause 13.4 of EN 300 444 [9]. 


NOTE: For values in the Attributes T req/cfm message, see table 35. 



1 0.9.2.2 Mt Attributes_T.req/cfm message 

The following fields as defined in EN 300 175-3 [3], clause 7.2.5.3.8 of the ATTRIBUTES_T.req/cfm messages shall 
be supported by the PT and the FT. 
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Table 35: Values used within ATTRIBUTES_T.req/cfm messages 



MAC message 


Field within the message 


Standard values 

within the MAC 

message 


Normative action/comment 


« Mj message » 








< Mj header > 


0001 


"Advanced connection control". 


< Command > 


6 


"Attributes T.request". 




7 


"Attributes T.confirm". 


<ECN> 


7 


ECN = 7 for ULE connection. 
Other values allowed for other 
applications. 


<LBN> 


1 to 15 


LBN = 15 shall be used for initial 
setup. Other values allowed in 
case of bearer replacement. 


< up/down/ss/sm > 


"11 "B 


Symmetric single bearer 
connection 


< service type > 


7 


lpQR_error_correct 


< max. lifetime > 


1 to 7 


Values 1 to 7 mandatory to support 


< slot type > 





Full slot Mandatory. Other slots 
optional 


<Cp> 


[0,1] 


Support of Cp optional. 


< extended (B + Z) field 
mod. type > 





(extended (B + Z) field not used). 


< adaptive code rate > 





No coding used (see note 2). 


< A-field modulation type > 


3 


Default modulation scheme to use 
for bearer setup is 2-level 
modulation. 


< (B + Z) field mod. type > 


3 


Default modulation scheme to use 
for bearer setup is 2-level 
modulation (see note 1). 


NOTE 1 : Modulation schemas other default modulation schema are for further study. 
NOTE 2: Use of encoded protected services and adaptive code rate is for further study. 



1 0.9.3 A-field connection/bearer release 

The procedure shall be performed as defined in EN 300 175-3 [3], clauses 10.4 and 10.7.2.1. 

The procedure may be used if the connection is either, basic or advanced. The proper value shall be inserted in the Mj 
header. 



MAC-DIS.Req 



PT 



RELEASE 




RELEASE 



MAC-DIS.Ind 



Figure 7: Bearer release 
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10.9.3.1 Mt message 

The following fields as defined in EN 300 175-3 [3], clause 7.2.5.2 in the MAC control (M-p) message shall be 
supported by the PT and the FT. 

Table 36: Values used within Mj message 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


«Mj message» 








<Mj header> 





Basic connection control 




1 


Advanced connection control 


<Command> 


15 


Release 


<FMID> 


All 


Basic connections only 


<LBN> 


All 


Advanced connection control only 


<reason> 


All 


Advanced connection control only 


<PMID> 


All 


See clause 13.4 of EN 300 444 [9] 



1 0.9.4 A-field bearer handover request 

The procedure shall be performed as defined in EN 300 175-3 [3], clauses 10.6.2 and 10.5.1.1. 

The procedure is equivalent for intra- and inter-cell handover. 

The procedure may be used if the connection is either, basic or advanced. The proper value for the Mj header shall be 
used. 

The FT should not release the old bearer within 10 ms after the establishment of the new bearer. 

10.9.4.1 Mt message 

The following fields as defined in EN 300 175-3 [3], clause 7.2.5.2 in the MAC control (Mj) message shall be 
supported by the PT and the FT. 

Table 37: Values used within Mj message 



MAC message 


Field within the 
message 


Standard values within 
the MAC message 


Normative action/comment 


«Mj message» 








<Mj header> 








1 


"Advanced connection control". 


<Command> 


1 


"Bearer handover request". 




4 


"Bearer confirm". 




5 


"Wait". 


<FMID> 


All 




<PMID> 


All 


See clause 13.4 of EN 300 444 [9]. 



1 0.9.5 A-field connection inandover request 

The procedure shall be performed as defined in EN 300 175-3 [3], clauses 10.2.4.2 and 10.5.1.1. 

The procedure may be used if the connection is either, basic or advanced. The proper value for the Mj header shall be 
used. 

The procedure is equivalent for intra- and inter-cell handover. 
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10.9.5.1 Mt message 

The following fields as defined in EN 300 175-3 [3], clause 7.2.5.2 in the MAC control (M-p) message shall be 
supported by the PT and the FT. 

Table 38: Values used within Mj message 



MAC message 


Field within the 
message 


Standard values within 
the lUIAC message 


Normative action/comment 


«Mj message» 








<Mj header> 








1 


"Advanced connection control". 


<Command> 


2 


"Connection_handover_request". PT 
shall capable to send. FT shall be 
capable to process. 




4 


"Bearer confirm". 




5 


"Wait". 


<FMID> 


All 




<PMID> 


All 


See clause 13.4 of EN 300 444 [9]. 



1 0.1 A-field (Mt) Expedited operations for Advanced Connection 
control 

10.10.1 General 

The expedited bearer setup procedures are optimized advanced Mt setup procedures intended for ultra fast setup of 
bearers, allowing in most cases reduction in the number of messages and early U-plane transmission compared to 
regular procedures. 

Expedited messages are only used for resume (bearer setup of existing MAC connections) or suspend (bearer release 
without clearing the connection at MBC level). 

Expedited bearer setup procedures are only defined as PT initiated. However, once initiated by the PT, FT may change 
the continuation of the procedure. 

Expedited messages may coexist with other advanced connection control set messages. 

1 0.1 0.2 IVIt advanced control messages for expedited operations 



10.10.2.1 Supported Mt messages 

The PT and FT shall support the following Mt advanced control messages from the Advanced connection control part 2 

set (see EN 300 175-3 [3], clauses 7.2.5.12.1 and 7.2.5.12.2): 

"Expedited Access Request" (command "0000"B) 
"Expedited Access Request ready for release" (command "0001 "B) 
"Null or Gfa channel transmission" (command "0010"B) 
"Ready for release with Gp^ transmission" (command "11 10"B) 
"Expedited Release with Gp^ transmission" (command "1111 "B) 

The PT and FT shall support the following Mt advanced control messages from the Advanced connection control set 

(see EN 300 175-3 [3], clauses 7.2.5.3.1 and 7.2.5.3.6): 

• "Bearer confirm" (command "0100"B) 
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10.10.2.2 



GpA transmission 



The PT and FT shall include a Gp^ message indicating last valid DLC RN (positive ACK) in all transmissions of 
"expedited release" and "ready for release" messages. 

1 0.1 0.2.3 Reason codes in "expedited release" and "ready for release" messages 
1 0.1 0.2.3.1 Reason codes in "expedited release" message 

The following reason codes shall be supported by both peers in the "expedited release" message 

Table 39: Supported "reason codes" in "expedited release" message 



Reason code 


Meaning 


Info field 


322 


^23 


324 


325 


326 


327 

















1 


Normal bearer release (see note 1 ) 


Not used, note 9 








1 





1 





base station busy (see note 2) 


Not used, note 9 








1 


1 





1 


unacceptable PMID / Unregistered PMID 
(see note 3) 


Not used, note 9 








1 


1 


1 


1 


Stay in LCE paging detection mode 
(see note 5) 


Code indicating paging 
mode and timer information, 
see note 5 





1 














switch to circuit mode (see note 4) 


See note 1 





1 











1 


Stay in higher paging detection mode 
(see note 6) 


Code indicating paging 
mode and timer information, 
see note 6 





1 








1 





setup again after n frames (see note 7) 


Code indicating number of 
frames for the setup 
attempt, note 7 





1 





1 








No such connection / virtual circuit, 
(see note 8) 


Not used, note 9 


NOTE 1 : This is tine 'normal' release reason code for a release of packet mode connections. 

NOTE 2: The applicable procedure is defined in clause 10.10.5.1 of the present document. 

NOTE 3: This reason code shall be used as response to Expedited access requests attempts when the PT is not 

registered at the RFP. See also clause 10.10.5.2 in the present document. 
NOTE 4: The applicable procedure is defined in clause 10.10.5.3 of the present document. 
NOTE 5: The exact meaning of the info field is defined in EN 300 175-3 [3], clause 7.2.5.12.5.2. The applicable 

procedure is defined in clause 10.10.5.5 of the present document. 
NOTE 6: The exact meaning of the info field is defined in EN 300 175-3 [3], clause 7.2.5.12.5.3. The applicable 

procedure is defined in clause 10.10.5.6 of the present document. 
NOTE 7: The exact meaning of the info field is defined in EN 300 175-3 [3], clause 7.2.5.12.5.4. The applicable 

procedure is defined in clause 10.10.5.7 of the present document. 
NOTE 8: This reason code shall be used as response to Expedited access requests attempts when there is no 

associated context (suspended IVIAC connection / suspended link / Virtual call) for the initiating PT. See 

also clause 10.10.5.7 in the present document. 
NOTE 9: Unused bits in 'info' field shall be set to '0'. 
NOTE 10: The contents and meaning of this info field are described in clause 10.10.5.4 of the present document. 



The procedures described in clause 10.10.5 shall be followed for the use of reason codes other than "Normal bearer 
release". 

1 0.1 0.2.3.2 Reason codes in "ready for release" message 

The following reason codes shall be supported by both peers in the "ready for release" message. 
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Table 40: Supported "reason codes" in "ready for release" message 



Reason code 


Meaning 


Info field 


322 


323 


324 


325 


326 


327 

















1 


Normal bearer release (see note 1 ) 


Not used, note 9 








1 





1 





base station busy (see note 2) 


Not used, note 9 








1 


1 





1 


unacceptable PMID / Unregistered PMID 
(see note 3) 


Not used, note 9 








1 


1 


1 


1 


Stay in LCE paging detection mode (see 
note 5) 


Code indicating paging 
mode and timer information, 
see note 5 





1 














switch to circuit mode (see note 4) 


See note 10 





1 











1 


Stay in higher paging detection mode 
(see note 6) 


Code indicating paging 
mode and timer information, 
see note 6 





1 








1 





setup again after n frames (see note 7) 


Code indicating number of 
frames for the setup 
attempt, note 7 





1 





1 








No such connection / virtual circuit, 
(see note 8) 


Not used, note 9 


NOTE 1 : This is the 'normal' release reason code for a release of packet mode connections. 

NOTE 2: The applicable procedure is defined in clause 10.10.5.1 of the present document. 

NOTE 3: This reason code shall be used as response to Expedited access requests attempts when the PT is not 

registered at the RFP. See also clause 10.10.5.2 in the present document. 
NOTE 4: The applicable procedure is defined in clause 10.10.5.3 of the present document. 
NOTE 5: The exact meaning of the info field is defined in EN 300 175-3 [3], clause 7.2.5.12.5.2. The applicable 

procedure is defined in clause 10.10.5.5 of the present document. 
NOTE 6: The exact meaning of the info field is defined in EN 300 175-3 [3], clause 7.2.5.12.5.3. The applicable 

procedure is defined in clause 10.10.5.6 of the present document. 
NOTE 7: The exact meaning of the info field is defined in EN 300 175-3 [3], clause 7.2.5.12.5.4. The applicable 

procedure is defined in clause 10.10.5.7 of the present document. 
NOTE 8: This reason code shall be used as response to Expedited access requests attempts when there is no 

associated context (suspended IVIAC connection / suspended link / Virtual call) for the initiating PT. See 

also clause 10.10.5.7 in the present document. 
NOTE 9: Unused bits in 'info' field shall be set to '0'. 
NOTE 10: The contents and meaning of this info field are described in clause 10.10.5.4 of the present document. 



The procedures described in clause 10.10.5 shall be followed for the use of reason codes other than "Normal bearer 
release". 

1 0.1 0.2.4 Operation codes in "Null or Gp^channel transmission" message 

The following operation code shall be supported by both peers in the "Null or Gp^channel transmission" message 
• "01"B: Gp^channel 
NOTE: See EN 300 175-3 [3], clause 7.2.5.12.5. 

10.10.3 Expedited procedures 

The following expedited procedures shall be supported. 

1 0.1 0.3.1 Procedure for Single-burst setup and release 

The PT and FT shall support the Procedure for Single-burst setup and release as defined by EN 300 175-3 [3], 
clause 10.5.1.8.2. 

1 0.1 0.3.2 Procedure for Multi-burst setup 

The PT and FT shall support the Procedure for Multi-burst setup as defined by EN 300 175-3 [3], clause 10.5.1.8.3, 
including the modification single-burst setup > Multi burst setup and the FT response table defined by 

EN 300 175-3 [3], clauses 10.5.1.8.3.2 and 10.5.1.8.3.3. 
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1 0.1 0.3.3 Announcement "Ready for Release" 

The PT and FT shall support the Procedure for announcement "Ready for Release" as defined by EN 300 175-3 [3], 
clause 10.5.1.8.4, including the protection as defined by EN 300 175-3 [3], clause 10.5.1.8.4.1. 

10.10.3.4 General Expedited Release procedure 

The PT and FT shall support the General Expedited Release procedure as defined by EN 300 175-3 [3], clause 10.7.3.2. 

1 0.1 0.3.5 Single-message expedited release procedure 

The PT and FT shall support the Single-message expedited release procedure as defined by EN 300 175-3 [3], 
clause 10.7.3.3.1. 

1 0.1 0.3.6 Abnormal expedited release procedure 

The PT and FT shall support the Abnormal expedited release procedure as defined by EN 300 175-3 [3], 
clause 10.7.3.3.2. 

1 0. 1 0.4 Expedited procedures use cases 

1 0.1 0.4.1 General use cases 

10.1 0.4. 1.1 Single Packet Data Transfer - Success 

Description: 

• Single-packet Data Transfer is designed to be as fast and simple as possible. It can even contain no data at all, 
and serve as a data pull request (PP->FP) only. 

• Single-packet Data Transfer will normally be preceded by a regular advanced connection which has negotiated 
service and slot type, and which has been suspended before. By default the single-packet data transfer uses IP 
error correct MAC service, single subfield protection, and full slot. The first messages do contain data. 

NOTE: The first IP packet transmitted on a new MAC packet mode connection has IP packet number 1 . 

These examples show a single packet PP to FP. These are designed to be simple and short as possible: 



REP 



May use a short slot 



PP 



access_request_release (BA=IP1) 



release (Q2=l, BCK=0, BA=no Bfield) 



Figure 8: Single Frame Data Transfer - Success 

There may be cases whether neither the PP, nor the FP has data to send (e.g. when the PP just polls the FP to 
see whether it has data, but the FP does not have any data). This flowchart would look exactly the same, only 
that the BA bits of the expedited_access_request_ready_for_release message would be 'no Bfield'). 
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This use case may happen as response to paging (indirect FT initiated setup) only in the event that the FT has 
no data to be sent downstream and PT has no data, or has a single packet ready to be sent upstream (the reason 
of the FT paging would be just a polling or an "stay-alive" checking). In the most usual case when the reason 
of the paging is sending data downstream, the use case is executed as shown in 10. 10.4. 1.3.1 (transfer of a 
single packet downstream) or further use cases in 10.10.4.1.3 (transfer of multiple packets). 



10.10.4.1.2 

10.10.4.1.2.1 
Description: 



Single Packet Data Transfer: error/abnormal cases 
Error in B-field CRC 



MAC signalling procedure is OK (A-field received and message decoded),), but due to a corrupted B-field the 
IP packet has not been received. 

In this case, the PP should understood that the packet has not been accepted and should try to retransmit it. 

The bearer is released and the PP has to repeat access request (on a different slot/carrier). 

The release reason may be "normal release" since the A-field was received OK, or "setup again in k frames" in 
order to trigger a subsequent setup process. 

If normal release reason is sent, the PP will reattempt the setup immediately. 



RFP 



May use a short slot 



PP 



access_request_release (BA=IP1) 



release (Q2=0, BCK=1, BA=no Bfield) 



10.10.4.1.2.2 
Description: 



Figure 9: Single Frame Data Transfer - A-field OK, B-field CRC Error 



No advance of BCK 



MAC signalling procedure is OK (A-field received and message decoded). B-field CRCs have been received 
OK. However received side cannot process the IP packet (due f.i.to overflow or to implementation constrains) 
and send BCK without advancing. 

In this case, the PP should understood that the packet has not been accepted and should try to retransmit it (on 
a separate bearer setup attempt). 

Otherwise, it is similar to previous case. 
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RFP 



May use a short slot 



PP 



access_request_release (BA=IP1) 



release (Q2=l, BCK=1, BA=no Bfield) 



Figure 10: Single Frame Data Transfer - B-field CRC OK, but no advance of BCK 

1 0.1 0.4.1 .2.3 Error in the procedure - Retries 

Description: 

• Error in the setup procedure 

Possible causes of the error: 

• Collision: there may be collision between multiple ULE transmitters trying to access at the same time 

• Radio interference or fading 



RFP 



PP 



access_request_release (BA=IP1) 



access_request_release (BA=IP1) 



release (Q2=l, BA=no Bfield) 



access_request_release (BA=IP1) 



release (Q2=l, BA=no Bfield) 



^ 



These retries are 
effectively new setup 
attempts on new channels 
derived from the packet 
mode bhnd slot and PSCN 



J 



Figure 11 : Single Frame Data Transfer - Retries 

10.10.4.1.2.4 The FP cannot accept the setup procedure 

Possible reasons: 

• The FP refuses the setup due to temporary congestion or other implementation reason 
the release reason "repeat again in k frames" may be used 
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• The FP does not know the PP (PP not registered) 

the release reason "unacceptable PMID / Unregistered PMID" may be used 

• The FP knows the PP, but there is not a VC active 

the release reason "No such connection / virtual circuit" may be used 

The last two cases may happen f.i. after a reset or a power loss of the RFP. A proper release reason will help the PP to 
handle the error case (starting the right NWK procedure). 

In all cases, the U-plane packet cannot be accepted. But the information is needed in order to instruct the PP how to 
handle the case and continue the procedure: 

• In general, the PP will have to start NWK layer procedures (CC or MM) 
Q2 and BCK settings (in release message): 

• Q2 shall be set according to real CRC decoding (so it will sent quality feedback to the PP) 

• For BCK, the recommended practice is setting it as BCK = 1 (repetition) 



RFP 



May use a short slot 



PP 



access_request_release (BA=IP1) 



release (reason x,Q2=l, BCK=1, BA=no Bfield) 



10.10.4.1.3 
Description: 



Figure 12: Single Frame Data Transfer - Abnormal release sent by the FP 



Multi Packet Data Transfer 



Multi-packet Data Transfer will normally be preceded by a regular advanced connection which has negotiated 
service and slot type, and which has been suspended before. By default the multi-packet data transfer uses IP 
error correct MAC service, single subfield protection, and full slot. The first messages do contain data. 

The first IP packet transmitted on a new MAC packet mode connection has IP packet number 1 . 

For the release of a packet mode connection the following applies: 

One peer knows first that both ends have successfully transferred their data, when: 

■ Its own 'ready_for_release' command that it sent with valid IP data was acknowledged by the other 
end (using the Q2 bit). 

■ It has received an error free ready_for_release command from the other end. 

The peer that knows first, that both ends have successfully received their data starts sending the 'release' 
command. This release message may use a short slot. 

A two-message release procedure (general expedited release) is used, to reduce the active transmitter 
time in the ULE device. 

FT initiated (indirect) setups, when the FP has data to be sent, are always implemented as a multi-burst data 
transfer with two release messages, even if only a single packet FT => PT is exchanged (see use 
case 10.10.4.1.3.1). 
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10.10.4.1.3.1 FT initiated (indirect) setup, only one packet FT => PT sent 

Description: 

• The FT has a single U-plane packet to be sent downstream. The PT has no data to be sent upstream. 

• The initial setup message should be "Expedited_access_request_ready_for_release" with BA code = "no 
B-field" (see EN 300 175-3 [3], clause 10.5.1.8.5). 



May use a short slot 



RFP 



Paging procedure 



access_request_release (BA=no B-field) 



ready_for_release (Q2=l, Ql=l, BA=IP1) 



release (Q2=l, BCK=0. BA=no BField) 



release (Q2=l, BCK=0, BA=no BField) 



PP 




Q2=1,Q1 = 1 



Here the PP knows that 
the FP has no more data 
to be sent, and initiates a 
general release procedure 



Same slot/carrier as 
first message 



Figure 13: FT initiated (indirect) setup, only one paclcet FT => PT sent 

10.10.4.1 .3.2 Multi Packet Data Transfer: Two-way single packet 

Description: 

• This example shows the simplest multi packet transfer. PP and RFP have 1 IP packet each. 

• A two-way single packet transfer FT initiated looks exactly the same with the only difference of the paging 
procedure. 



May use a short slot 



RFP 



access_request_release (BA=IP1) 



ready_for_release (Q2=l, BCK=0, BA=IP1) 



release (02=1. BCK=0, BA=no BField) 



release (Q2=l, BCK=0, BA=no BField) 



PP 




Q2=l 
BA=IP1 



Here the PP knows both 
ends have received the 
last packet, and sends a 
release 



Same slot/carrier as 
first message 



Figure 14: Two-way Single Packet Data Transfer 
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10.10.4.1.3.3 



Description: 



Multi Packet Data Transfer: PP sends 4, FP sends 1 , showing the "connected" state 
point 



• This example shows a multi packet transfer. PP has more data to send than RFP (PP sends 4 IP packets, FP 
sends 1 IP packets). 

• The use case shows when the TBC connected state is reached. 



RFP sets the TBC state to 
"connected" at this point 



Here the RFP knows 
both ends have received 
the last packet, and sends 
a release 



RFP confirms the last 
IPO packet with this 
release message 



RFP 



access_request (BA=IP1) 



ready_for_release {Q2=l, BCK=0, BA=IP1) 



other (Q2=l, BCK=0, BA=IPO) 



other (Q2=l, BCK=1, BA=no Bfield) 



other (Q2=l, BCK=0, BA=IP1) 



other (Q2=l, BCK=0, BA=no Bfield) 



ready_for_release (Q2=l, BCK=0, BA=IPO) 



release (Q2=l, BCK=1, BA=no Bfield) 



release (Q2=l, BCK=0, BA=no Bfield) 



Only here the RFP knows the data 
transfer was completed successfully for 
the PP and resumes setup scanning (this 
is why we need acknowledged release) 



PP 



PP sets the TBC state to 
"connected" at this point 



May use a short slot 



Figure 15: Multi Packet Data Transfer - Success 

NOTE 1: See EN 300 175-3 [3], clause 10.5.1.8.7 for description on when the TBC connected state is reached. 

NOTE 2: The general policy is sending ready for release only once (as the diagram). However, the 
ready_for_release should be ACK OK (Q2 = 1). Otherwise it should be repeated. 

NOTE 3: The ready for release effect cannot be cancelled. However it the RFP receives data to be sent downstream 
and wish to transmit further data, it may use the "setup again" code in the release message. 



10.10.4.1.3.4 
Description: 



Multi Packet Data Transfer: PP sends 1 , FP sends 4 



• This example shows a multi packet transfer. RFP has more data to send than PP (PP sends 1 IP packet, FP 
sends 4 IP packets). 
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RFP 



May use a short slot 



access_request_release (BA=IP1) 



Bearer confirm (Q2=l, BA=IP1) 



other (Q2=l, BA=no BField) 



other (Q2=l, BA=IPO) 



other (Q2=l, BA= no Bfield) 



other (Q2=1,BA=IP1) 



other (Q2=l, BA= no Bfield) 



ready_for_release (Q2=l, BA=no BField) 



release (Q2= 1 , BA=no Bfield) 



release (Q2=l, BA=no Bfield) 



PP 



Here the PP knows both 
ends have received the 
last packet, and sends a 
release 



PP confirms the last 
IPO packet with this 
release message 



Figure 16: Multi Packet Data Transfer - Success 

NOTE: When the PP has no data to send at all, this flowchart would look exactly the same with the difference 
that that the BA bits of the expedited_access_request_ready_for_release message would be 'no Bfield'). 

10.10.4.1.3.5 Multi Packet Data Transfer: PP sends 2, FP sends 2 

Description: 

• This example shows a multi-burst transfer. PP and RFP have 2 IP packets each to send. 
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May use a short slot 



RFP 



PP 



access_request (BA=IP1) 



confirm (Q2=l, BCK=0, BA=IP1) 



ready_for_release (Q2=l, BCK=0, BA=IPO) 



ready_for_release (Q2=l, BCK=1, BA=IPO) 



release (Q2=l, BCK=1. BA=no BField) 



release (Q2=l, Ql=l, BA=no BField) 



Here the PP knows both 
ends have received the 
last packet, and sends a 
release 



May use a short slot 



Figure 17: Multi Packet Data Transfer: PP sends 2, FP sends 2 - Success 

1 0.1 0.4.1 .3.6 Multi Packet Data Transfer: PP sends 2, FP sends 2 - Error in one release message 

Description: 

• This example shows a multi-burst transfer. PP and RFP have 2 IP packets each to send. 

• There is an error in one release message. 



Not received 



RFP 



PP 



access_request (BA=IP1) 



confirm (Q2=l, BCK=0, BA=IP1) 



ready_for_release (Q2=l, BCK=0, BA=IPO) 



ready_for_release (Q2=l, BCK=1, BA=IPO) 



^ release (02=1, BCK=1. BA=no BField) 
ready_for_release (Q2=0, Q1=0, BA=IPO) 



release (Q2=l, BCK=1, BA=no BField) 



release (Q2=l, Ql=l, BA=no BField) 



Here the PP knows both 
ends have received the 
last packet, and sends a 
release 



May use a short slot 



Figure 18: lUluIti Pacl<et Data Transfer: PP sends 2, FP sends 2 - Success - Error in 

one release message 
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10.10.4.1.3.7 



Multi Packet Data Transfer: FP traffic only (3 U-plane packets) - Success 



Ql == Ql as previous 
received BA='no 
BField'i.e. E-IVlux 



Ql may be always 
set to wlien ,no 
BField' was received. 
Or it may be used to 
indicate sliding 
collision. 



May use a short slot 



RFP 



Paging procedure 



access_request release (no B-field) 



B confirm (Q2=l, Ql = 1, BA=IP1) 



other (Q2=l, BCK=0, BA= no field) 



other (Q2=l, Ql = 1, BA=1P0) 



other (Q2=l, BCK=1, BA= no Bfield) 



ready_for_release (Q2=l, Ql = 1, BA=IP1) 



release (Q2= 1 , BCK=0, BA=no Bfield) 



release (Q2=l, Ql = 1, BA=no Bfield) 



PP 



Send Ql bit meaning 
(Ql or BCK) depends on 
previously received BA 
bits (E- or U-Mux Mode) 



Here the PP knows this 
is the last FP packet 



PP confirms the last 
IPOpacket with this 
release message 



Figure 19: Multi Pacl<et Data Transfer - FP traffic only (3) - Success 

The PP will start the procedure with: 

• Access Request Release: if it has nothing to be sent upstream. 

• Access Request: if it has something to be sent. 
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10.10.4.1.3.8 



Multi Packet Data Transfer: FP traffic only (3 U-plane packets) - Retransmit 



Retransmit of IPO 



RFP 



c 



pp 



access_request release (no B-field) 



Bearer_confirm (Q2=l, Ql = 0, BA=IP1) 



other (Q2=l, BCK=0. BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=0, Q1=0, BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=l, BCK=1, BA= no Bfield) 



ready_for_release (Q2=l, Ql = 0, BA=IP1) 



release (Q2=l, BCK=0, BA=no Bfield) 



release (Q2=l, Ql = 0, BA=no Bfield) 



Send Ql bit meaning 
(Ql or BCK) depends on 
previously received BA 
bits (E- or U-Mux Mode) 



BField Mode unknown here 

=> Q1=Q1=0 

Q2=0 indicates this to the FP 



Figure 20: Multi Packet Data Transfer - FP traffic only (3) - Retransmit 

The PP will start the procedure with: 

• Access Request Release: if it has nothing to be sent upstream. 

• Access Request: if it has something to be sent. 
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10.10.4.1.3.9 Multi Packet Data Transfer: FP traffic only (3 U-plane packets) - running empty in the 

middle 



Running empty (tennporarly 
no data to send) 



A full slot has to be used 
(use of short slot Is not 
allowed here) 



Data available again 



RFP 



access_request release (no B-field) 



Bearer.confirm (Q2=l, Ql = 0, BA=IP1) 



other (Q2=l, BCK=0, BA= no B field) 



other (Q2=l, Ql = 0, BA= no B field) 



other (Q2=l, Q1=0, BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=l, BCK=1, BA= no Bfield) 



ready_for_release (Q2=l, Ql = 0, BA=IP1) 



release (Q2=l, BCK=0, BA=no Bfield) 



release (Q2=l, Ql =0, BA=no Bfield) 



PP 



Send Ql bit meaning 
(Ql or BCK) depends on 
previously received BA 
bits (E- or U-Mux Mode) 



Figure 21 : Multi Pacl<et Data Transfer - FP traffic only (3 U-plane packets) - 

running empty in the middle 
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10.10.4.1.3.10 Multi Packet Data Transfer: FP traffic only (3 U-plane packets) - Retransmit due to 

congestion 



Retransmit of IPO after PP 
has indicated congestion 



RFP 



c 



access_request release (no B-field) 



Bearer_confirm (Q2=l, Ql = 0, BA=IP1) 



other (Q2=l, BCK=0, BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=l, BCK=0, BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=l, BCK=1, BA= no Bfield) 



ready_for_release (Q2=l, Ql = 0, BA=IP1) 



release (Q2=l, BCK=0, BA=no Bfield) 



release (Q2=l, Ql =0, BA=no Bfield) 



PP 



Congestion at PP side, cannot 
accept IPO now => BCK = 



Congestion resolved at PP 
side, asking for IPl now => 
BCK = 1 



Figure 22: Multi Pacl<et Data Transfer - FP traffic only (3 U-plane packets) - 
Retransmit due to congestion 

1 0.1 0.4.2 C-plane related use cases 

1 0.1 0.4.2.1 Multi Packet Data Transfer: FP requested C-plane traffic only - Success 

Description: 

• FP requested setup to execute a C-plane procedure. 

• In the example, there is C-plane traffic only. 

For practical purposes, it may be assumed that the C-plane operation requested by the FP is an MM 
authentication. 
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Cs procedure 
continues as 
required 



RFP 



PP 



Paging procedure (not shown) 



access_request release (no B-field) 



Bearer_confirm (Q2=l, Ql=l, BA=no B field) 



ready_for_release (Q2=l, Ql=l, BA= no field) 



CS (Q2=l, Ql=l, BA=no B-field) 



CS (Q2=l, Ql=l, BA= no Bfield) 



other (Q2=l, Ql=l, BA= no Bfield) 



other (Q2=l,Ql=l,BA=no Bfield) 



CS (Q2=l, Ql= 1, BA=no B-field) 



CS (Q2=l, Ql=l, BA= no Bfield) 



Ready_for_release (Q2=l, Ql=l, BA=no Bfield) 



release (Q2=l, Ql=l, BA=no Bfield) 



release (Q2=l, Ql=l, BA=no Bfield) 



Bearer confirm is used 
here. Other more 
efficient options (i.e. 
starting Cs) are at 
discretion of the 
implementer 



Here, there is an 
interruption in the Cs due 
to other T-mux priority 



End of Cs activity is 
indicated by a "ready for 
release" message 



Here the PP knows this is 
the last packet, and sends 
a release 



Figure 23: Multi Packet Data Transfer - FP req. C-plane traffic only - Success 

1 0.1 0.4.3 Stay alive related use cases 

1 0.1 0.4.3.1 PT initiated stay alive with transmission of Gfa from FT 

Description: 

• Stay alive handshake designed as a short single-burst transfer process, but without U-plane. 

Successfully handshake requires correct reception of release with Q2=l and any of the following reason codes in the 
release message: 

• Normal bearer release. 

• Stay in higher paging detection mode (paging mode and timer in info field), the PP shall obey the command. 

• Setup again after n frames (in that case the PP shall obey the instructions for the setup). 
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The procedure does not qualify for the handshake and the PP will move to an intermediate state (and repeat again the 
handshake attempt) if: 

• No reception of release. 

• Bad Q2 report (Q2 = 0) received (with the release message). 

• Reception of release reason "base station busy". 

The procedure does not qualify for the handshake and the PP will move directly to loss of handshake state if: 

• No such connection / virtual circuit. 

• Unacceptable PMID / Unregistered PMID. 



May use a short slot 



RFP 



PP 



access_request_release (BA=no B-field) 



release (Q2=l, Ql=l, BA=no Bfield,) 



Figure 24: Stay alive - PT initiated- Success 

NOTE: A DLC ACK message is transmitted via the Gfa channel in the FT => PT message. 

1 0.1 0.4.3.2 PT initiated stay alive - the FT changes the procedure to start a C-plane 

procedure 

Description: 

• It starts as a stay alive handshake. The FP decides to keep the bearer by changing the procedure to a multi- 
burst setup. This is done by replying "bearer confirm" to the setup. Instead of sending U-plane packets, the FP 
starts a Cs transmission. 

• The procedure continues as 10.10.4.2.1 "Multi burst data transfer: FP requested C-plane traffic only -Success". 

• The procedure qualifies as a handshake. 
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RFP 



PP 



access_request_release (Q2=0, Q1=0, BA=no B-field) 



bearer confirm (Q2=l, Ql = 1 BA=no B-field) 



other (Q2=l, Ql = 1 BA= no Bfield) 



CS (Q2=l, Ql=l, BA=no B-field) 



CS (Q2=l, Ql = 1, BA=no Bfield) 



Procedure continues as 10.10.4.2.1 and also 
qualifies for a handshake 



The bearer confirms 
changes the procedure. It 
also makes the handshake 
successful 



Figure 25: Stay alive - PT initiated- Success and thie FT chianges thie procedure to start C-plane 

procedures 

NOTE: A DLC ACK command is transmitted via the Gfa channel in the two last releases (both ways allowed) 
after the termination of the C-plane procedure. 



10.10.4.3.3 



PT initiated stay alive - the FT changes the procedure to send U-plane data 



Description: 

• It starts as a stay alive. The FP decides to keep the bearer changing the procedure to multi-burst. This is done 
by replying "bearer confirm" to the setup. The procedure continues as a multi-burst transfer. 

• It also qualifies as a handshake. The reception of the "bearer confirm" makes the handshake successful. 



RFP 



PP 



access_request_release (Q2=0, Q1=0, BA=no B-field) 



bearer confirm (Q2=l, Ql = 1 BA=1P1) 



other (Q2=l, BCK=0, BA= no Bfield) 



ready_for_release (Q2=l, Ql =1, BA=IPO) 



release (Q2=l, BCK= 1, BA=no Bfield) 



release (Q2=l, Ql=l, BA=no Bfield) 



The bearer confirms 
changes the procedure. It 
also makes the handshake 
successful 



Figure 26: Stay alive - PT initiated- Success and the FT changes the procedure to send 

two U-plane packets 
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10.10.4.4 Failure and Retransmission Use cases 
10.10.4.4.1 Setup Failure and Retransmission Examples 

This clause shows some scenarios where the packet mode connection setup fails, and where re-transmission is applied. 
The BA header codes and Q bit settings are omitted mostly for clarity reasons. 

In the examples below the red lightning indicates that the message was not received error free. 



10.10.4.4.1.1 



Error in access message 



In case of error in the reception of the Access request message (A field cannot be decoded by the FP) the expected FP 
response is no action. 



RFP 





pp 


access_request/access_request_release 











10.10.4.4.1.2 



Figure 27: Packet Mode Connection setup fail (access message wrong) 



Error in confirmation message 



This following flowchart shows a scenario where the first message FP => PP is lost. The PP then does not send 
anything anymore, and starts a new setup attempt on a new channel. The FP starts an unacknowledged release 
procedure. 



No response 
from the PP 
=> 

unacknowled 
ged release 



RFP 



access_request/access_request_release 



ready_for_release/confirm < 



PP 



no message sent by the portable 



Release (Q2=0) 



10.10.4.4.1.3 



Figure 28: Packet IVIode Connection setup fail (confirm message wrong) 



Error in "otiner" message 



The following flowchart shows the scenario where the 3' message is not received in the RFP. Again in that case the FP 
starts an unacknowledged release procedure. 
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Only after the first .other' 
message is received properly, 
both ends know that the 
bearer can get data through 
the B-field in both directions. 

Otherwise - if the FP did not 
get the other, it does not know 
whether the 

confirm/ready_for_release 
had been received by the PP 



RFP 



access_request 



confirm / ready_for_release 



other 



release (Q2=0) 



PP 



Figure 29: Packet Mode Connection setup fails (other message wrong) 

Only one release message shall be sent. There is no timing to send this release (it is sent in next frame). This response 
will be mandatory. 



10.10.4.4.1.4 
Description: 



Error in the second "other" message 



The flowchart below shows the retransmission of the second other (4' message). 



RFP 



access_request 



ready _for_release 



other (Q2=1,BA=IP0) 



other (Q2=l, no Bfield) 



other (retrans, Q2=0. BA=IPO) 



other (Q2=l, no BField) 



ready_for_release (BA=IP1) 



release (Q2=l) 



release (Q2=l) 



PP 



nd 



Figure 30: Pacl<et lUlode Connection success (2 other message retransmitted) 
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10.10.4.4.2 



Release Failure and Retransmission Examples 



10.10.4.4.2.1 

Description: 



Error in the "release" message 



• This flowchart shows a single two-way packet transfer, were the first release message is not received. As this 
is a 'multi packet data transfer', and this release message is the 3"* message, the packet mode connection is 
considered to be failed. The FP starts an unacknowledged release procedure. 



RFP 



\. 



access_request_release 



ready_for_release 



release 



release (Q2=0) 



PP 



Figure 31 : Two-way Single Pacl<et lUlode Connection (1^' release message wrong) 



10.10.4.4.2.2 
Description: 



Error in the second "release" message 



In the flowchart below it is the second release message that is not received. Here the release message is re- 
transmitted. 

RFP shall be able to receive the retransmitted release message. 
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RFP shall be able to 
receive this 
retransmitted 
release message 



RFP 



PP 



access_request_release 



ready_for_release 



release (Q2=l) 



release 



M 



release (Q2=0) 



release (Q2=l) 



Figure 32: Two-way Single Packet IVIode Connection (release retransmitted) 

10.10.4.4.2.3 Error in the "release" message causing a retransmission of the "ready for release" 

The following two flowcharts show re-transmission of the "ready for release" message. 



RFP 



access_request (BA=IP1) 



confirm (Q2=1,BA=1P1) 



ready_for_release (Q2=l, BA=1P0) 



ready_for_release (Q2=l, BA=1P0) 



release (02=1, BA=no BField) 



ready_for_release (Q2=0, BA=IPO) 



release (Q2=l, BA=no BField) 



release (Q2=l, BA=no BField) 



PP 



Here the PP knows both ends 
have received the last packet, 
and sends a release 



PP must be able to 
handle 

read y_for_re lease 
OR release here 



Figure 33: Multi Packet Data Transfer - Error in the "release" message causing 
a retransmission of the "ready for release" 
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Upon receiving the "ready_for_release" message, the PP knows that both ends have received the last packet, and 
therefore sends a release. If the RFP does not receive the "release" message and therefore sends again a 
"ready_for_release" (in blue in figure 33), the PP shall be able to handle it and release here (i.e. sending back to the RFP 
a "release" message). 



10.10.4.4.2.4 



Error in a "ready for release" message causing its retransmission 



RFP 



PP 



access_request (BA=IP1) 



confirm (Q2=1,BA=IP1) 



ready_for_release (Q2=l, BA=IPO) 



ready_for_release (Q2=l, BA=IPO) 



ready for relea.se (02=0. BA=IPO) 



ready_for_release (Q2=l, BA=IPO) 



release (Q2=l, BA=no BField) 



release (Q2=l, BA=no BField) 



Here the PP knows both ends 
have received the last packet, 
and sends a release 



Figure 34: Multi Packet Data Transfer for "DF Sweet Spot" (ready for release retransmit case 2) 

As shown in figure 34, the PP does not receive Q2 feedback to a "ready_for_release" message and therefore retransmits 
the message (in blue). Upon receiving back from the RFP another "ready_for_release" message (in blue), the PP knows 
that both ends have received the last packet, and therefore sends a "release" message. 



10.10.4.4.3 



Errors when in TBC "connected" state 



10.10.4.4.3.1 Retransmission abandoned and abnormal release of the TBC due to multiple 

errors 

Description 

• This flowchart shows how data retransmission is abandoned when the data is not going for 3 re-transmissions. 



ETSI 



102 



ETSI TS 102 939-1 VI. 1.1 (2013-04) 



No new data or valid 
received for 3 frames => 
Start unacknowledged 
release procedure 



RFP 



r 



< 



V. 



PP 



access_request 



ready _for_release 



Other (Q2=1,BA=IP0) 



other (Q2=l, no Bfield) 



other (Q2=0, BA=IPO) 



^ 



other (Q2=0, no BField) 



other (Q2=1,BA=IP0) 



other (Q2=l, no BField) 



other (Q2=0, BA=IPO) 



release (Q2=0, 'setup again') 



release (Q2=0, 'setup again') 



release (Q2=0, 'setup again') 



release (Q2=0, 'setup again') 



> 



Data not going for 3 re- 
transmits => Start 
unacknowledged release 
procedure 



PP can stop sending 
releases if it receives c 
release 



Figure 35: Packet Mode Connection fails (retransmission abandoned) 



10.10.4.4.4 



Intrusion and interference use cases 



10.10.4.4.4.1 

Description: 



Intrusion of a Ready for release with wrong identity intrusion, continuing transmission 



This flowchart shows the behaviour when a wrong identity is received on one of the messages. This can 
happen if the chosen channel is hijacked by a foreign DECT device. The end that receives the wrong identity 
starts an unacknowledged release procedure. The packet mode connection is deemed to fail. 



ETSI 



103 



ETSI TS 102 939-1 VI. 1.1 (2013-04) 



RFP 



PP 



access_request (BA=IP1) 



confirm (Q2=1,BA=IP1) 



ready_for_release (Q2=l, BA=IPO) 



ready_for_release (Q2=l, BA=IPO) 



ready_for_release (Q2=0, Ql=l=noBfield,) 



ready_for_release (Q2=l, Ql=l, BA=IPO) 



From foreign RFP 



Bearer confirm (PMID/FMID wrong) 



Figure 36: Intrusion of a Ready for release with wrong identity intrusion, continuing transmission 

1 0.1 0.4.4.4.2 Intrusion of a Ready for release with wrong identity intrusion, causing its 

retransmission 

Description: 

• This flowchart shows the behaviour when a wrong identity is received on one of the messages. This can 

happen if the chosen channel is hijacked by a foreign DECT device. The end that receives the wrong identity 
starts an unacknowledged release procedure. The packet mode connection is deemed to fail. 



RFP 



PP 



access_request (BA=IP1) 



confirm (Q2=1,BA=IP1) 



ready_for_release (Q2=l, BA=IPO) 



ready_for_release (Q2=l, BA=IPO) 



ready_for_release (Q2=0, BA=no Bfield,) 



ready_for_release (Q2=l, BA=IPO) 



From foreign RFP 



Bearer confirm (PMID/FMID wrong) 



Figure 37: Intrusion of a Ready for release with wrong identity intrusion, causing its retransmission 

The bearer when TBC is in connected state should not be aborted after a single intrusion. The case is handled as not 
reception of the frame. The TBC will be aborted after three errors. 
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1 0.1 0.4.4.5 Errors in release procedures 

10.10.4.4.5.1 Multiple errors in release: abandoned release retransmission 

General remark: 

• In any case one should bear in mind that these are all exceptional error cases only. 
Figure 38 shows release retransmission: 



FP must be ready to 
receive another release 
here ! Keep the receive 
slot on a fixed carrier 



RFP 



PP doesn't stop sending 
releases => stop ACK'ing 
them. 



access_request (BA=IP1) 



confirm (Q2=1,BA=IP1) 



ready_for_release (Q2=l, BA=IPO) 



ready_for_release (Q2=l, BA=IPO) 



release (02=1, BA=no BField) 



release (Q2=l, BA=no BField) 



release (Q2=0, retrans) 



release (Q2=0, retrans) 



release (02=0. retrans) 



release (Q2=l, retrans) 



release (02=0, retrans) 



release (Q2=l, retrans) 



PP 



> 



The PP needs to receive this 
release message in order to be 
sure the FP received the ACK 
for the last data it sent 



Release not ACK'ed for 3 
re-transmits => Just stop 



J 



Figure 38: Multi Packet Data Transfer - Abandoned release retransmission (option 1) 

The above mechanism is based on the following principles: 

• The peer that knows all data has been passed (the one that receives the second ready_for_release message) 
starts sending release messages. 

• If it does not get anything back, it stops after 3 retransmissions. 

• If it gets a release back the procedure ends. 

• If it gets another ready_for_release, the release message retransmit counter is restarted. In case of continuous 
problems i.e. when ready_for_release is received again and again, the procedure then would end when the 
other side abandons sending the ready_for_release. 
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1 0.1 0.4.4.6 Data transfer use cases showing the response to the BCK bit and to transitions 

between BA codes 



10.10.4.4.6.1 



Multi Packet Data Transfer: FP traffic only (3 U-plane packets) - Success 



Ql == Ql as 
previous received 
BA='no BField' i.e. 
E-Mux 



Ql may be always 
set to when ,no 
BField' was received. 
Or it may be used to 
indicate sliding 
collision. 



RFP 



c 



access_request release (no B-field) 



Bearer_confinn (Q2=l, Ql = 0, BA=1P1) 



other (Q2=l, BCK=0. BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=l, BCK=1, BA= no Bfield) 



ready_for_release (Q2=l, Ql = 0, BA=IP1) 



release (Q2=l, BCK=0, BA=no Bfield) 



release (Q2=l, Ql = 0, BA=no Bfield) 



PP 



Send Ql bit meaning 
(Ql or BCK) depends 
on previously received 
BA bits (E- or U-Mux 
Mode) 



Figure 39: Multi Packet Data Transfer - FP traffic only (3) - Success 
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10.10.4.4.6.2 



Multi Packet Data Transfer: FP traffic only (3 U-plane packets) - Retransmission 



Retransmit of IPO 



RFP 



c 



pp 



access_request release (no B-field) 



Bearer_confirm (Q2=l, Ql = 0, BA=IP1) 



other (Q2=l, BCK=0. BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=0, Q1=0, BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=l, BCK=1, BA= no Bfield) 



ready_for_release (Q2=l, Ql = 0, BA=IP1) 



release (Q2=l, BCK=0, BA=no Bfield) 



release (Q2=l, Ql =0, BA=no Bfield) 



Send Ql bit meaning 
(Ql or BCK) depends 
on previously received 
BA bits (E- or U-Mux 
Mode) 



BField IVIode unl(nown here 

=> Q1=Q1=0 

Q2=0 indicates this to the FP 



Figure 40: Multi Paclcet Data Transfer - FP traffic only (3) - Retransmission 
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10.10.4.4.6.3 



Multi Packet Data Transfer: FP traffic only (2 U-plane packets) - running empty 



Running empty (temporarily 
no data to send) 



Data available again 



RFP 



access_request release (no B-field) 



Bearer.confirm (Q2=l, Ql = 0, BA=IP1) 



other (Q2=l, BCK=0, BA= no B field) 



other (Q2=l, Ql = 0, BA= no B field) 



other (Q2=l, Q1=0, BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=l, BCK=1, BA= no Bfield) 



ready_for_release {Q2=l, Ql = 0, BA=IP1) 



release (Q2= 1 , BCK=0, BA=no Bfield) 



release (Q2=l, Ql = 0, BA=no Bfield) 



PP 



Send Ql bit meaning 
(Ql or BCK) depends 
on previously received 
BA bits (E- or U-Mux 
Mode) 



Figure 41 : Multi Pacl<et Data Transfer - FP traffic only (3) - running empty 
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10.10.4.4.6.4 Multi Packet Data Transfer: FP traffic only (3 U-plane packets) - Retransmit after 'no 

advance' (due to congestion) 



Retransmit of IPO after PP 
has indicated congestion 



RFP 



C 



access_request release (no B-field) 



Bearer_confirm (Q2=l, Ql = 0, BA=IP1) 



other (Q2=l, BCK=0. BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=l, BCK=0, BA= no Bfield) 



other (Q2=l, Ql = 0, BA=IPO) 



other (Q2=l, BCK=1, BA= no Bfield) 



ready_for_release (Q2=l, Ql = 0, BA=IP1) 



release (Q2= 1 , BCK=0, BA=no Bfield) 



release (Q2=l, Ql = 0, BA=no Bfield) 



PP 



Congestion at PP side, cannot 
accept IPO now => BCK = 



Congestion resolved at PP 
side, asking for IPl now => 
BCK = 1 



Figure 42: Multi Packet Data Transfer - FP traffic only (3) - Retransmit due to congestion 

10.10.4.4.6.5 Multi Packet Data Transfer: FP and PP send 2 packets each - Congestion in 'Ready 

for Release' transfer (I) 

There may be some special difficulties with 'no advance' scenarios during the MAC expedited connection release phase. 
This scenario and the following give some focus on this. 

The general the rule is: 

• For the release of a packet mode connection the following applies: 

One peer knows first that both ends have successfully transferred their data, when: 

■ Its own 'ready_for_release' command that it sent with valid IP data was acknowledged by the other 
end (using the Q2 bit) 

■ It has received an error free ready_for_release command from the other end 

■ There is no congestion ('no advance' scenario) pending on either end 

The peer that knows first, that both ends have successfully received their data starts sending the 'release' 
command. This release message may use a short slot 

A crossed (acknowledged) release procedure is used, to reduce the active transmitter time in the ULE 
device 
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• So as long as a 'no advance' scenario is pending no end is allowed to start the acknowledged release 

• Both sides should take into account the MAC maximum packet hfetime as upper limit for the retransmissions 



Congestion at FP side, cannot 
accept IPO now => BCK = 
i.e. FP asks for IPO again 



Congestion resolved at FP 
side, now FP knows all data 
transfer completed and starts 
releasing 



RFP 



access_request (Q2=0, BA=IP1) 



bearer_confirm (Q2=l, BCK= 0, BA=IP1) 



ready_for_release (Q2=l, BCK=0, BA=IPO) 



ready_for_release (Q2=l, BCK=0, BA=IPO) 



readv_for_release (Q2=l, BCK=1, BA=IPO) 



release (Q2=l, BCK=1, BA=no Bfield) 



release (Q2=l, Q1=0, BA=no Bfield) 



PP 



Here the PP knows the FP has 
nothing more to send. 
However its own data are not 
through due to congestion => 
don't send release here 
(repeats readY_for_release) 



Retransmit of IPO with 
'ready_for_release' because 



CD u^.. :n^:..K*A^ . 



Figure 43: Multi Packet Data Transfer: FP and PP send 2 packets each - Congestion in 'Ready For 

Release' transfer (I) 

10.10.4.4.6.6 Multi Packet Data Transfer: FP and PP send 2 packets each - Congestion in 'Ready 

for Release' transfer (II) 

Description: 

• Use case: Multi Packet Data Transfer: FP and PP send 2 packets each. Congestion in 'Ready For Release' 
transfer II (later phase). 
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PP already has send 

all Its data so It may 

switch to a short slot 

(No BFIeld) here 



Retransmit of IPO with 

'ready_for_release' after PP 

has Indicated congestion 



RFP 



access_request (Q2=0, BA=IP1) 



bearer_confirm (Q2=l, BCK=0 = 0, 



ready_for_release (Q2=l, BCK=0, BA=IPO) 



ready_for_release (Q2=l, BCK=1, BA=IPO) 



PP 



ready_for_release (Q2=l, BCK=0, BA=IPO/no BField) 



ready_for_release (Q2=l, BCK=1/Q1=0, BA=IPO) 



release (Q2= 1 , BCK= 1 , B A=no Bfield) 



release (Q2=l, Q1=0, BA=no Bfield) 



Congestion at PP side, cannot 
accept IPO now. PP knows It 
needs retransmission from FP => 



Congestion resolved at PP 
side, PP now can start 
releasing 



Figure 44: Multi Packet Data Transfer: FP and PP send 2 packets each - Congestion in 'Ready For 

Release' transfer II 

10.10.4.4.6.7 Multi Packet Data Transfer: FP sends 2 packets and PP sends 3 packets - Congestion 

in 'Ready For Release' transfer (I) 



Here the FP knows the PP has 

nothing more to send. 

However Its own data are not 

through due to congestion => 

don't send release here 

(repeats ready_for_release) 



Retransmit of IPO with 
'ready_for_release' because 
PP has Indicated congestion 



RFP 



access_request (Q2=0, BA=IP1) 



bearer_confirm (Q2=l, BCK=0, BA=IP1) 



other (Q2=l, BCK=0, BA=IPO) 



ready_for_release (Q2=l, BCK=1, BA=IPO) 



ready_for_release (Q2=l, BCK=0, BA=IP1) 



ready_for_release (Q2=l, BCK=0, BA=IPO) 



release (Q2=l, BCK=1, BA=no Bfield) 



release (Q2=l, Q1=0, BA=no Bfield) 



PP 



Congestion at PP side, cannot 
accept IPO now => BCK = 

i A DD '.r-lAf tr^r IDA -.n-In 



Congestion resolved at PP 
side, PP can now start 
releasing 



Figure 45: Multi Packet Data Transfer: FP sends 2 packets and PP sends 3 packets - Congestion in 

'Ready For Release' transfer (I) 
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10.10.4.4.6.8 



Description: 



Multi Packet Data Transfer: FP sends 2 packets and PP sends 3 packets - Congestion 
in 'Ready For Release' transfer (II) 



• Multi Packet Data Transfer: FP send 2 packets and PP sends 3 packets. Congestion in 'Ready for Release' 
transfer II (later phase). 



Congestion at FP side, cannot 
accept IPl now. FP knows it 
needs retransmission from PP => 
FP doesn't send release here 
(repeats ready_for_release) 



Congestion resolved at FP side, 
now FP knows all data transfer 
completed and starts releasing 



RFP 



PP 



access_request (Q2=0, BA=IP1) 



bearer.confirm (Q2=l, BCK= 0, BA=IP1) 



other (Q2=l, BCK=0, BA=IPO) 



ready_for_release (Q2=l, BCK=1, BA=IPO) 



ready_for_release (Q2=l, BCK=1, BA=IP1) 



ready_for_release (Q2=l, BCK=1, BA=IPO/no Bfield) 



ready_for_release (Q2=l, BCK=0/Q1=0, 



release (Q2=l, BCK=0, BA=no Bfield) 



release (Q2=l, Q1=0, BA=no Bfield) 



Here the PP knows the FP 
has nothing more to send 



FP already has send all its 
data so it may switch to a 
short slot (No BField) here 



PP's data are not through due 

to congestion in FP => 

don't send release here 

Retransmit of IPl with 

'ready_for_release' because 

FP has indicated congestion 



Figure 46: Multi Pacl<et Data Transfer: FP send 2 paclcets and PP sends 3 pacl<ets - Congestion in 

'Ready For Release' transfer II (later phase) 

1 0.1 0.5 Use of reason codes in "expedited release" and "ready for release" 
messages 

1 0.1 0.5.1 Use of reason code "normal bearer release" 

This is the normal situation at the end of a ULE packet transaction, the release reason is "normal bearer release" which 
instructs the PT to return to Idle. 

This reason code shall be used by both, the FT and the PT, unless there is a reason for using any other code. 
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FT 



PT 



Packet mode 



release 



reason = "normal bearer release" 



Inform higher layer of 
release and reason 

Go to idle 



(implementation) 



Idle 



Figure 47: Use of reason code "normal bearer release" 

1 0.1 0.5.2 Use of reason code "base station busy" 

The release reason "base station busy" indicates that the RFP is too busy to continue handling the connection with PT. 
Oppositely to the reason code "Setup again after n frames", no explicit action is mandated. 

It is expected that the PT will retry the access (including new channel selection process) after a timer. The value of 
such timer is left to the implementer. 

1 0.1 0.5.3 Use of reason code "unacceptable PMID / Unregistered PMID" 

The release reason "unacceptable PMID / Unregistered PMID" is used to indicate to the PT that the PT is not registered 
in the RFP. This can be the result of an abnormal situation, such as reset of the RFP. 

The expected response shall be the PT to execute Mobility Management procedures in order to register again the PT in 
the RFP. After MM, CC Service Change may be executed in order to resume the connection. See clause 12.1.3.1. 

1 0.1 0.5.4 Use of reason code "switch to circuit mode" 

The release reason "switch to circuit mode" is used to request to the PT that a circuit mode connection should be started. 
The requested circuit mode service is indicated by the info field as shown in table 41. In figure 48, the PT behaviour at 
the end of the ULE service call is shown as returning to idle but the actual action is controlled by the PT application. 

Table 41 : Info field for Release Reason code "switch to circuit mode" 



Info field 


bitsa17toa21) 


Requested action 


a17 


a18 


a19 


a20 


a21 

















Reserved for only MAC setup 














1 


Start ULE service call 











1 





Start Location registration 











1 


1 


Reserved for start GAP voice call (outgoing) 








1 








Reserved for LCE procedures 








1 





1 


} 


to 


} reserved 


1 1 1 1 1 1 1 1 1 


1 



In all cases, the MAC setup shall be basic connection (full slot). 
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FT 



PT 





Packet mode 








release 






reason = "switch to circuit mode" 
info field = 1 

^ CC-SETUP 


Inform higher layer of 




release and reason 
^ Start ULE service call 








basic service ULE service call 
CC-CALL-PROC 














ULE service call mes^^^ 








CC-RELEASE 








CC-RELEASE-COM 








Inform higher layer ^ 




Go to idle 




(implementation) 



Idle 



Figure 48: Use of reason code "switch to circuit mode" and setup ULE service call 

1 0.1 0.5.5 Use of reason code "Stay in LCE paging detection mode" 

The release reason "stay in LCE paging detection mode" is used to instruct the PT to enter a mode where it can Hsten 
for LCE paging. Being able to respond to LCE paging lets the FT initiate circuit mode transactions, the example given 
here is of deregistration of a ULE node. 

Both, normal and fast LCE paging may be supported. The duration of the listening to LCE paging state and the paging 
cycle (normal or high) is given in the info field. The coding of the info field is defined in EN 300 175-3 [3], 
clause 7.2.5.12.5.2. 

The message sequence chart below shows the actions if the PT finds an LCE page before the hstening period times out. 
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FT 



PT 



Packet mode 



higher layer request 



e.g. terminate node 



4. . . . PP.T.in un i cat ion ^ 

with iiiglier layer 



release 



reason = "stay in LCE paging detection mode" 



A-field Pt paging 



with TPUl 



establish traffic bearer 



LCE-PAGE-RESPONSE 



-ACCESS-RIGHTS-TERM 



etc 



traffic bearer release 



Idle 



Inform higher layer of 



release and reason 
Go to listen mode 



(HDC, NDC, LDC 
implementation) 



listen 



listen 



communication 



wjith higher layer 



Inform higher layer 
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Figure 49: Use of reason code "Stay in LCE paging detection mode": LCE paging 

If the PT does not receive an LCE page before the timeout period it should stop Ustening and return to idle. 



£75/ 



115 



ETSI TS 102 939-1 VI. 1.1 (2013-04) 



FT 



PT 



Packet mode 



release 



reason = "stay in LCE paging detection mode" 



Inform higher layer of 



release and reason 



Go to listen mode 



(HDC, NDC, LDC 
implementation) 



listen 



listen 



listen 



listen 



: timeout; 

Inform higher layer 



Goto idle 



(implementation) 



Idle 



Figure 50: Use of reason code "Stay in LCE paging detection mode": timer expiration 

10.10.5.6 Use of reason code "Stay in higher paging detection mode" 

The release reason "stay on higher paging detection mode" is used to cause the PT to stay listening for a ULE page 
message with a different paging cycle from the standard one. This feature is used in slow paging cycle devices, such as 
PP type 1 (sensors), when the FT may have the need to send data to such PP sooner than the regular paging cycle. 

The duration of the higher paging detection mode is given in the info field. The coding of the info field is defined in 

EN 300 175-3 [3], clause 7.2.5.12.5.3. 

In the case covered by the raise ULE call in N frames operation the FT is not in a position to immediately service the 
PT, perhaps because the application needs time to respond. If the FT is not confident that it will have a response it can 
use stay locked for ULE page as a release reason instead of raise call in N frames. If there is an application response the 
FT can page the PT which will then raise a bearer. If there is no application response there will be no page and the PT 
does not waste energy or bandwidth by raising an unneeded bearer. The listening period is specified in the information 
field of the release reason and is counted in paging cycles of the paging descriptor (in paging cycles of the fastest 
descriptor if more than one has been allocated). 
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Figure 51 : Use of reason code "Stay in higher paging detection mode": paging event 

If the PT does not receive a ULE page before the timeout period it should stop hstening and return to idle. 
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Figure 52: Use of reason code "Stay in higher paging detection mode": timer expiration 

1 0.1 0.5.7 Use of reason code "Setup again after n frames" 

The release reason "set up again" is used to instruct the PT to attempt to estabhsh a ULE packet mode connection at 
some future time. It could be used if the FT is too busy to deal with the original packet mode connection or if it cannot 
respond to the PT immediately (a delay in the application layer). The delay before re-establishing is specified in the 
information field of the release reason. 

The delay value is coded as defined in EN 300 175-3 [3], clause 7.2.5.12.5.4. The maximum value is 31 frames. 

The standard rules for ULE channel selection shall apply. The PT may start looking the channel selection info in the 
dummy bearer just before the expiration of the timer in order to perform the setup after n frames. 

It is not possible to guarantee that the call will be raised after exactly N frames, it will depend on the availability of slots 
among other things; the value of n should be considered as a minimum time: a call will not be raised before n frames 
have passed. Additionally, the value should be treated as a suggestion from the FT thus allowing the PT to 
independently determine how many frames to wait. 

NOTE: The action of the PT during the wait period is essentially an implementation decision however it may 
depend on the length of the suggested delay. If the delay is short it may not be possible or advisable to 
loose and regain sync, for a longer delay it may be worthwhile for the PT to enter a lower power state. 
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Figure 53: Use of reason code "Setup again" 

1 0.1 0.5.8 Use of reason code "No such connection / virtual circuit" 

The release reason "No such connection / virtual circuit" is used to indicate that the PT is known at the RFP (PP 
registered), however the NWK layer PVC is not in active state and the DLC link and MAC MBC are not created. 
Therefore, expedited operations cannot be used yet and any attempt to setup a bearer with expedited procedures shall 
result on a Mj Release response with this Reason code. 

The expected response from the PT is to execute NWK C-plane procedures in order to resume the NWK transaction and 
re-create the link and the MBC. The Service change procedures described at clause 12.1.3.1 shall be used. 

10.11 Slot types and slot use 
10.11.1 Full Slot 

10.11.1.1 General 

The D-field mapping for the full slot structure (physical packet P32), as defined by EN 300 175-3 [3], clause 6.2.1.1.2 
shall be supported. 
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The B-field mapping for the full slot structure (physical packet P32), as defined by EN 300 175-3 [3], clause 6.2.1.3.1.2 
shall be supported. 

1 0.11 .1 .2 Use of full slot in C/0 bearers 

Full slot shall be used in C/O bearers, in all cases except in the cases listed in clause 10.1 1.2.2, when short slot may also 
be used. 

1 0.1 1 .1 .3 Use of full slot in C/L dummy bearers 

Full slot shall be used in the dummy C/L bearers in all cases. 

10.11.2 Short Slot 

10.11.2.1 General 

The D-field mapping for the short slot structure (physical packet POO), as defined by EN 300 175-3 [3], clause 6.2.1.1.2 
shall be supported in both FT and FT, at least in receiving mode. Use (transmission) of the slot is optional at both sides. 

The B-field mapping for the full slot structure (physical packet POO), as defined by EN 300 175-3 [3], clause 6.2.1.3.1.3 
shall be supported in both FT and FT, at least in receiving mode. Use (transmission) of the slot is optional at both sides. 

1 0.1 1 .2.2 Use of short slot in C/O bearers 

In order to further save energy, it is allowed to transmit as short slots frames that do not carry any B-field (BA code = 
no B-field) in certain cases. 

The use of short slots is optional at sending side (transmitter choice). However its understanding by the receiving side is 
mandatory. 

The rules given in EN 300 175-3 [3], clause 10.5.1.8.9 shall apply in full extend and shall be fulfilled. 

In addition to that, the following additional rule shall apply: 

• After using a short slot, it is not allowed to roll back to full slot. Therefore all subsequent transmissions shall 
be short slots and no further U-plane may be send by the peer over that TBC. 

10.12 I channel services 

10.12.1 Protected I channel error_correct service 

The FT and FT shall support protected I channel operation in error_correct mode as defined in EN 300 175-3 [3], 
clause 10.8.2. 

The Ip_error_correct mode shall apply to the Ip service IpQj^_error_correct. 

10.12.1.1 Unilateral jump 

FT and FT shall support unilateral data jump procedure according to EN 300 175-3 [3], clause 10.8.2.5.2. 

10.12.1.2 Bearer reset 

FT and FT shall support bearer reset according to EN 300 175-3 [3], clause 10.8.2.5.3. 
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1 0. 1 2.2 Lifetime management witin TWO separate maximum MAC pacl^et 
lifetimes 

The FT and PT shall operate with TWO separate maximum MAC packet lifetimes, differentiating the maximum 
lifetime at the bearer (at TBC level) and the maximum lifetime at the MAC layer, as described in EN 300 175-3 [3], 
clauses 10.8.2.2.1.2 and 10.8.2.2.1.3. 

The detailed provisions given in EN 300 175-3 [3], clause 10.8.2.2.1.3 shall apply. 

The operation of the counters shall be as described in EN 300 175-3 [3], clause 10.8.2.2.1.4. 

The following specific provisions shall apply: 

The MAC control message "Attributes_T" shall be used for setting the maximum packet lifetime at the TBC and the 
NWK layer IE « TRANSIT-DELAY » shall be used for setting the maximum packet lifetime at the MAC layer. 

When the maximum TBC lifetime expires, in addition to stop further re-transmissions over the same TBC, the bearer 
should be released and a new bearer should be established (bearer replacement) where further re-transmissions may 
happen (if allowed by the overall packet lifetime). The process of setting up the new TBC (bearer replacement) may 
start before the expiration of the TBC lifetime. 

10.13 GpAciiannel 
10.13.1 Gfa cinannel data 

10.13.1.1 Gfa channel transmission 

The transmitter side of FT and PT shall support the Gp^ channel transmission as defined in EN 300 175-3 [3], 
clause 5.3.1.3 over the following Mj messages: 

• ready for release with Gp^ transmission 

• expedited_release with Gp^ transmission 

• Null or GpA channel transmission 

1 0.1 3.1 .2 Gfa channel reception 

The receiver side of FT and PT shall support the of Gp^ channel reception, as defined in EN 300 175-3 [3], 
clause 5.3.1.3 and shall understand the frame format FUlOd when transmitted over the Gp^ channel. 

The receiver side (FT or PT) shall be able to understand Gp^ channel messages when transmitted over the following Mj 

messages: 

• ready for release with Gp^ transmission 

• expedited_release with Gp^ transmission 

• Null or Gfa channel transmission 

10.14 C channel operation 
10.14.1 Cs channel 

FT and PT shall support Cg channel data transmission and reception as defined in EN 300 175-3 [3], clauses 10.8.1 
and 10.8.1.1. 
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10.14.2 Cf channel 



FT and PT shall support Cp channel data transmission and reception as defined in EN 300 175-3 [3], clauses 10.8.1 
and 10.8.1.2. However, the priority of Cp channel over U-plane shall be ruled as defined in the next clause. 

For ULE devices, the use of Cp channel and its priority is negotiated by means of the NWK layer IE <Connection 
Attributes>, see EN 300 175-5 [5], clause 7.7.11, that is performed during call setup and optionally at any time 
(CC-Service Change). 

Once such negotiation has been performed, the use of Cp and the Cp setting in MAC control messages (Attributes) 
should follow the decision taken at NWK layer. 

Before such negotiation is done, or in absence of it, the use of Cp is controlled by a flag in MAC "Attributes" command. 
For indirect FT initiated setup, the code "0101" in LCE paging "field 2: setup info" (see EN 300 175-5 [5], 
clause 8.2.2), indicates to the PT that may start using channel Cp. In such case, the NWK layer call setup may be 
performed over Cp. 

In absence of "Attributes" exchange, or the reception of the setup info code "0101" in LCE paging, the initial NWK 
layer call setup shall be performed over C^, switching to Cp only after NWK layer negotiation. 

The suspension and resume of any ULE connection does not change the setting of Cp. Both peers shall use Cp, or not, 
as before the suspension. 

A FT or PT that has indicated that it supports Cp channel (see clause 10.3.2.2.1 for the FT and 12.3 for the PT), shall 
accept the setting of Cp in the NWK layer negotiation. 

If Cp channel is active, all C-plane transmission shall take place preferably on the Cp channel. However, it is allowed to 
use Cg channel if Cp channel has priority D (lowest) and there is no interruption in the U plane data flow. 

1 0.1 4.2.1 Priority schema of the Cp channel 

This clause defines the relative priority of the Cp channel over U-plane (I-channels) and other B-field control channels 
in ULE connections. 

In ULE, it is possible to select the priority level of Cp channel by means of the NWK layer IE <Connection Attributes> 
(see EN 300 175-5 [5], clause 7.7.11). The setting is done by means of octets 6 and 6a. 

The priority schema of the different B-field channels shall be as defined in EN 300 175-3 [3], clause 6.2.2.4 (Priority 
scheme in E or Eh-U mode) with the following exceptions and specific provisions: 

• The priority of all channels except Cp channel shall be shall be as defined in the clause 6.2.2.4 of 
EN 300 175-3 [3]. 

• The priority of channel Cp and its retransmissions depends on the negotiated value of the fields "Cp channel 
attributes" in the Information Element <Connection Attributes> (see EN 300 175-5 [5], clause 7.7.1 1): 

a) Cp channel attribute = "101" = Priority A (highest): 

Channel Cp has always priority over U-plane data. The priority of Cp versus U plane and other channels 
is exactly as described in EN 300 175-3 [3], clause 6.2.2.4. Cp channel may use all duplex bearers in a 
multibearer connection and always with priority over U plane. 
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b) Cp channel attribute = " 1 00" = Priority B : 

shall not be used 

c) Cp channel attribute = "010" = Priority C: 

Channel Cp has less priority than U-plane data (as priority D), until a time limit of 250 ms. If there is Cp 
data buffered and waiting for transmission longer than 250 ms, then the priority is changed to priority B 
(priority over U plane in one bearer). 

d) Cp channel attribute = "001" = Priority D (lowest): 

Channel Cp has always less priority than U-plane data. The priorities of Cp channel retransmissions and 
fresh data are reduced to priorities 9 and 10 in the list described in EN 300 175-3 [3], clause 6.2.2.4. Cp 
channel may only be transmitted if there is no U plane data to fill in all bearers. 

e) Cp channel attribute = "000" = no Cp channel: 

There is no Cp channel. All higher layers C-plane traffic is routed through the Cg channel. 



10.15 MAC Encryption control 



The following clauses refer to the Encryption process performed at MAC layer as defined in EN 300 175-7 [7], 
clauses 6.4.4 and 6.4.5. Refer to clause 1 1.10 for the CCM encryption operating at DLC layer. 

10.15.1 Encryption process - initialization and synchronization 

The procedure shall be performed as defined by EN 300 444 (GAP) [9], clause 10. 13. 
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1 0. 1 5.2 Encryption mode control 
10.15.2.1 General 

The procedure shall be performed as defined in EN 300 444 (GAP) [9], clause 10.14 and EN 300 175-7 [7], 
clause 6.4.6. 

Figure 54 summarizes the sequence and timing of MAC encryption control procedures. 
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Figure 54: MAC Encryption control procedures 
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10.15.2.2 Mt message 

The provisions of EN 300 444 (GAP) [9], clause 10.14.1 shall apply. 

1 0.1 5.2.3 Procedure for enabling encryption 

10.15.2.3.1 Prerequisite 

In order to execute the MAC procedure for enabling encryption, it is a prerequisite that the NWK layer procedure 
Cipher-switching has been previously successfully executed with the Y/N value in «Cipher-info» indicating Cipher 
activation ("1"). 

Any of the following NWK layer procedures qualifies for the prerequisite: 

• Cipher-switching initiated by FT using DSC (clause 12.23. 1 1) 

• Cipher-switching initiated by PT using DSC (clause 12.23. 12) 

• Cipher-switching initiated by FT using DSC2 (clause 12.24.10) 

• Cipher-switching initiated by PT using DSC2 (clause 12.24.1 1) 

The use of DSC or DSC2 produces should be consistent with the cipher supported by the system. 

The MAC procedure may only be executed within a timer equivalent to <MM_cipher.l>: (defined in EN 300 175-5 [5], 
annex A) after the transmission of the {CIPHER-REQUEST} message in the NWK layer procedure. Otherwise the 
MAC shall not perform the MAC layer procedure, the receiving entity of any MAC layer procedure attempt shall reject 
the command, and the encryption state shall be kept unchanged. 

10.15.2.3.2 Procedure 

The connection should be in active state (it should be resumed if suspended). 

The PT-MAC shall start the encryption switching process on one bearer as described in EN 300 175-7 [7], 
clause 6.4.6.3. 

1 0.1 5.2.4 Procedure for disabling encryption 
10.15.2.4.1 Prerequisite 

In order to execute the MAC procedure for disabling encryption, it is a prerequisite that the NWK layer procedure 
Cipher-switching has been previously successfully executed with the Y/N value in «Cipher-info» indicating Cipher 
deactivation ("0"). 

Any of the following NWK layer procedures qualifies for the prerequisite: 

• Cipher-switching initiated by FT using DSC (clause 12.23. 1 1) 

• Cipher-switching initiated by PT using DSC (clause 12.23. 12) 

• Cipher-switching initiated by FT using DSC2 (clause 12.24.10) 

• Cipher-switching initiated by PT using DSC2 (clause 12.24.1 1) 

The use of DSC or DSC2 produces should be consistent with the cipher in use. 

The MAC procedure may only be executed within a timer equivalent to <MM_cipher.l>: (defined in EN 300 175-5 [5], 
annex A) after the transmission of the {CIPHER-REQUEST} message in the NWK layer procedure. Otherwise the 
MAC shall not perform the MAC layer procedure, the receiving entity of any MAC layer procedure attempt shall reject 
the command, and the encryption state shall be kept unchanged. 
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10.15.2.4.2 Procedure 

The connection should be in active state (it should be resumed if suspended). 

The PT-MAC shall start the encryption switching process on one bearer as described in EN 300 175-7 [7], 
clause 6.4.6.4. 

1 0. 1 5.3 Handover encryption process 

In ULE part 1, the handover encryption process is only used for circuit mode connections. 

For the ULE packet mode connection, bearer replacement shall be performed. See clause 10.20. 

For the handover encryption process of circuit-mode connections, the procedure shall be performed as defined in 

EN 300 175-7 [7], clause 6.4.7 

1 0.1 6 Enhanced security procedures 

10.16.1 Re-keying 

The procedure shall be performed as specified in EN 300 175-7 [7], clause 6.4.6.5. 

1 0. 1 6.2 Early Encryption 

The procedure shall be performed as specified in EN 300 175-7 [7], clause 6.4.6. 

10.16.3 DSC Encryption 

The procedures specified in EN 300 175-7 [7], clause 6.4 shall apply with the following specific requirements: 

• The DECT Standard Cipher (DSC) algorithm (see EN 300 175-7 [7], annex J) shall be used in the Key Stream 
Generator (KSG). 

• The Cipher Key used by the KSG shall have 64 bits. When the DSAA2 authentication algorithm is used, the 
64 least significant bits of the DCK generated by DSAA2 shall be used as Cipher Key for the KSG. 

10.16.4 AES/DSC2 Encryption 

The procedures specified in EN 300 175-7 [7], clause 6.4 shall apply with the following specific requirements: 

• The DECT Standard Cipher #2 (DSC2) algorithm (see EN 300 175-7 [7], annex M) shall be used in the Key 
Stream Generator (KSG). 

• The Cipher Key used by the KSG shall have 128 bits. 
NOTE: This is the size of the DCK generated by DSAA2. 



1 1 DLC layer procedures 

11.1 LU14 Eninanced Frame RELay service with CCM (EFREL- 
CCM) 

The procedure shall be performed as defined in EN 300 175-4 [4], clause 11.16. The following text together with the 
associated clauses defines the mandatory requirements with regard to the present document. 

The packet received from the U-plane apphcation layer shall be the LU14 SDU. 
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The LU14 SDU shall be encrypted using CCM as described in Service [ULE1-D.13], the CCM MIC shall be added, and 
the resulting packet shall be sent to the LUlO SAP to be further processed as described in Service [ULE1-D.3]. 

The reverse procedure shall be done at the receiving side. 

The received packet shall be only revealed and delivered to higher layers if the CCM MIC is decoded and checked 
correctly. In case of wrong CCM MIC, the packet shall be discarded and an error notification shall be sent to higher 
layer. 

The standard delivery mode (see LUlO description) shall be used. 

The maximum LU14 SDU size that shall be supported is defined in clause B.2.1. 

The maximum SDU size in use at a given time may be configured by means of C-plane procedures. See clause B.2.1. 

All provisions applicable to the LUlO processing, underlying layers and the transport protocol are given in Service 
[ULE1-D.2]. 

Only one instance of LU14 shall be supported between the same PT-FT pair: 

• The support of multiple instances of LU14 is for further study. 

11 .2 LU1 Enhanced Frame RELay service (EFREL) 

The procedure shall be performed as defined in EN 300 175-4 [4], clause 11.12. The following text together with the 
associated clauses defines the mandatory requirements with regard to the present document. 

The SDU shall be segmented into fixed length segments, where the segment length shall depend on the PDU structure 
chosen (see clause 11.3). 

The following MAC service shall be used: IpQR _error_correction. 
The transmission class 1 shall be used. 

Modulus shall be 512 for the send sequence number and 256 for the receive sequence number. The bit 9* of sending 
Sequence Number shall be provided and properly coded, however the receiving side may ignore this bit for DLC 
transmission protocol purposes since the window size is always < 128. The 9* bit shall be, however, used by the CCM 
decoder as explicit part of the CCM sequence number. 

The 9* bit shall never be coded in the receive sequence number. If FUlOd full format is used, the bit shall always be 
coded to "0". 

Implementations shall support a maximum LUlO SDU size equal to the maximum LU14 or LU13 SDU size plus 
4 octets. 

NOTE: The maximum LUlO SDU size is always equal to the maximum LU13 or LU14 SDU size plus 4 octets. 

11.2.1 Window size 

The window size can be negotiated in the range of 8 to 128 by the NWK-layer. 

The default value for the window size is 16. 

This default value will be used in absence or failure of NWK-Layer negotiation. 

Any ULE device shall support at least the following values for the window size: 8, 16 and 32. 

The window size in use at a given time may be negotiated by means of C-plane procedures. See clause 12.1.3 in the 
present document. 

1 1 .2.2 SDU transmission and delivery mode 

The standard delivery mode shall be used in all cases. 
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The option of transporting parts of several SDUs in one PDU shall not be used. Only one segment of one SDU shall be 
carried in each PDU. 



11 .3 FU1 framing (FU1 Oa, FU1 Od) 



The procedure shall be performed as defined in EN 300 175-4 [4], clause 12. 11. The following text together with the 
associated clauses defines the mandatory requirements with regard to the present document. 

11.3.1 FUlOa 

FUlOa frames as defined in see EN 300 175-4 [4], clause 12.11 shall be used for the forward path of unidirectional 
links. Bi-directional links may be implemented using two unidirectional links for each direction. FUlOa is the standard 
frame for carrying data in ULE. 

Modulus shall be 512 for the send sequence number. The bit 9* of sending Sequence Number shall be provided and 
properly coded, even if it is not needed by the DLC transmission protocol due to the window size. The receiving side of 
the DLC transmission protocol maj 
part of the CCM sequence number. 



the DLC transmission protocol may ignore this bit. The 9* bit shall be, however, used by the CCM decoder as explicit 



The option of transporting parts of several SDUs in one PDU shall not be used. Only one segment of one SDU shall be 
carried in each PDU. 

11.3.2 FUlOd 

11.3.2.1 General 

FUlOd frames as defined in see EN 300 175-4 [4], clause 12.1 1, with total length shall be used for the backward control 
path. 

Both, the shortened and the full format shall be supported: 

• Shortened format shall be used when the frame is transported over Gp^ channel, messages Mj "Expedited 
Release" and "Expedited Ready for Release". 

• Full format shall be used when the frame is transported over Gp^ channel, message Mj "Null or Gp^ packet", 
and using the insertion facility described in clause 1 1.3.2.1. 

When full format is used, the N/A bit shall always be coded to "1" (positive ACK). 

The 9* bit shall never be coded in the receive sequence number. If FUlOd full format is used, the bit shall always be 
coded to "0". 

1 1 .3.2.2 Transport of FU1 Od frames over Gfa channel 

The transport of FUlOd frame over channel Gp^ shall be supported in all cases: 

• Shortened format shall be used when the frame is transported over messages Mj "Expedited Release" and 
"Expedited Ready for Release". 

• Full format shall be used the frame is transported over message Mj "Null or Gp^ packet". 

1 1 .3.2.3 Insertion of FU1 Od frames In FU1 Oa frames of the opposite link 

The FT and PT shall support the transport of FUlOd frames by insertion in the frame FUlOa of the opposite link using 
the procedure described in EN 300 175-4 [4], clause 12.1 1.2.3. 
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The sending side can take dynamically the decision on how to transport the FUlOd frames according to traffic and use 
of the M J channel by the connection. 

NOTE: As general rule, if a suitable Mj message with Gp^ transport capability has to be sent due to MAC 
control reasons, this should be the preferred mechanism for sending the FUlOd frame. The use of the 
insertion mechanisms is only recommended in case of long bursts with the tail channel used by channels 
or operations which do not allow Gp^ transport. 



1 1 .4 Class A operation 



The class A link operation can be either PT or FT initiated. To simplify the description this clause considers on the PT 
initiated procedures; for the FT initiated procedures, "PT" shall be replaced with "FT" and vice versa. This is valid for 
the entire clause 11. 4 and the associated clauses. 

11.4.1 Class A link establishment 

The procedure shall be performed as defined in EN 300 175-4 [4], clause 9.2.3.1. The following text together with the 
associated clauses define the mandatory requirements with regard to the present document. 

If, class B acknowledged transfer is requested but not supported (B acknowledged transfer is not required to be 
supported for ULE) by the receiving side, the I_frame requesting class B operation shall be treated as though it was a 
class A fi-ame, see EN 300 175-4 [4], clause 9.2.4.3.1 b). 



PT 



FT 



DL-ESTABLISH-req 
► 



V(S) 


V(R) 


V(A) 











1 








1 





1 



I frame 



RR_response 



V(S) 



V(R) 



V(A) 



DL-ESTABLISH-ind 
► 



Figure 55: Class A link establishment 



£75/ 



129 



ETSI TS 102 939-1 VI. 1.1 (2013-04) 



Table 42: Values used within the l-frame 



Field 


Parameter within 
the field 


Standard values within 
the field/parameter 


Normative action/comment 


«Address-field» 








<NLF> 


1 


New link 


<LLN> 


1 


Class A operation 


<SAPI> 





Connection oriented 


<C/R> 





PT command 


<RES> 


1 




«Control-field» 








<N(R)> 





N(R) = V(R) 


<P> 





Ignore 


<N(S)> 





N(S) = V(S) 


«Length-indicator- 
field» 








<Li> 





No higher layer information 




1..63 


Higher layer info length 


<M> 


All 




<N> 


1 


No extended length field. If "0" the frame 
may be discarded 


«lnformation field» 




All appropriate 


Higher layer information. If <Li> field 
indicates "0" shall be omitted. This field 
shall be used to carry the 
{LCE-PAGE-RESPONSE} message in case 
of FT initiated indirect link establishment 


«Fill field» 




11110000B 


Ignore. to 4 such octets may be included 
in case for the Cg logical channel, as the 
Frame Length (FLEN) mod 5 = 0. If <Li> 
indicates "0", no <Fill filed> is required 


«Checksunn field1» 




All 


The contents shall be calculated using two 
elements: LSIG see EN 300 175-4 [4], 
clause 10.3.1; underlying checksum 
calculation based on ISO/IEC 8073 [14] 


«Checksum field2» 




All 


See above 



Table 43: Values used within the {RR-Frame} S-format message 



Field 


Parameter within 
the field 


Standard values within 
the field/parameter 


Normative action/comment 


«Address-field» 








<NLF> 


1 


New link 


<LLN> 


1 


Class A operation 


<SAPI> 





Connection oriented 


<C/R> 





FT response 


<RES> 


1 




«Control-field» 








<N(R)> 


1 


N(R) = V(R) 


<P/F> 





Ignore 


<SS> 







<***> 


1 


constant 


«Length-indicator- 
field» 








<Li> 





No higher layer information 


<M> 







<N> 


1 


No extended length field. If "0" the frame 
may be discarded 


«Checksum field1» 




All 




«Checksum field2» 




All 
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1 1 .4.1 .1 Associated procedures 



11.4.1.1.1 


<DL.07> 


value: 


start: 


stop: 


11.4.1.1.2 



Timer P<DL.07> management 

class A establishment timer; 

refer to EN 300 175-4 [4], annex A; 

a Class A link establishment I_frame is transmitted; 

on receipt of: a Class A errorless RR_response with the New Link Flag (NLF) bit set to "1"; a 
DL_RELEASE-req primitive indicating "abnormal"; a MAC_DIS-ind primitive. 

Re-transmission counter management 

Refer to EN 300 175-4 [4], clauses 9.2.3.1 and 9.2.3.6. 

Each LAPC entity shall maintain an internal Re-transmission count variable determining the maximum number of 
re-transmissions of an I_frame. The default value shall be 3. 

For Class A operations the Re-transmission counter shall be reset any time a new I_frame has been sent. 

1 1 .4.1 .1 .3 Multiple frame operation variables management 

Refer to EN 300 175-4 [4], clause 7.5.2. 

For the DLC layer acknowledged transfer to be performed the V(S), V(A), and V(R) operation variables together with 
their appropriate management shall be supported. 

The allowed values of all state variables for a given class of operation shall always be defined by the modulus 
operation. For Class A operation, the modulus equals 2. 



11.4.1.1.4 



Lower Layer Management Entity (LLME) establishment of a MAC connection 



The procedure shall be performed as defined in EN 300 175-4 [4], clause 10.2 and EN 300 175-3 [3], clause 8.1.1. The 
following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

For a link to be established a suitable MAC connection is needed. If such one does not exist the LLME shall request it. 



DLC 



MAC_CON-req 



MAC CON-cfm 



MAC 



Figure 56: Establishment of a lUIAC connection initiating side 
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Table 44: Values used within the MAC_CON-req primitive 



Parameter 


Information within the parameter 


Normative action/comment 


«MCEI» 


MAC Connection Endpoint Identifier 


RefertoEN300 175-4[4], 
clause 10.2.4.4 


«PMID» 


Portable part MAC Identity (PMID) 




«CHO flag» 


N 


N = Normal connection 

Y (connection required for Connection 

handover) is for further study 


«Old MCEI» 


Not used 


Only needed for Connection handover 
and Basic type connections 


« Cp required » 


0, 1 


Cp is optional. 


«Slot type» 


full slot 




«Service type» 


lpQR_error_correction 


Mandatory 


« up/down/sm/ss » 


ss 


11 (single bearer connection) 


«connection type» 


Advanced 




« ECN » 


7 


DLC requests an specific ECN value 
(expedited connection) 
See also EN 300 175-4 [4], 
clause 10.2.4.2 



Table 45: Values used within the l\/IAC_CON-cfm primitive 



Parameter 


Information within the parameter 


Normative action/comment 


«MCEI» 


MAC Connection Endpoint Identifier 


Refer to EN 300175-4 [4], 
clause 10.2.4.4 


«Connection type» 


Advanced 


The type of the established connection 


« ECN » 


7 


MAC confirms the ECN = 7 (expedited 

connection) 

See also EN 300 175-4 [4], 

clause 10.2.4.2 



The receiving side shall be informed about the action that has taken place in case it was successful by a MAC_CON-ind 
primitive. 



DLC 





MAC_CON-ind 


IVIAC 





Figure 57: Establishment of a MAC connection receiving side 
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Table 46: Values used within the MAC_CON-ind primitive 



Parameter 


Information within the parameter 


Normative action/comment 


«MCEI» 


IVIAC Connection Endpoint Identifier 


RefertoEN300 175-4[4], 
clause 10.2.4.4 


«PMID» 


PMID 




«CHO flag» 


N 


N = Normal connection 

Y (connection required for Connection 

handover) is for further study 


« Cp required » 


0, 1 


Cp is optional 


«Slot type» 


full slot 






lpQR_error_correction 


IVIandatory 


« up/down/sm/ss » 


ss 


11 (single bearer connection) 


« Connection type » 


Advanced 




« ECN » 


7 


IVIAC indicates that this is an ECN = 7 
expedited connection (see also 
EN 300 175-4 [4], clause 10.2.4.2) 



1 1 .4.1 .2 Exceptional cases 



11.4.1.2.1 



Timer P<DL.07> expiry 



If a RR response is received with the NLF bit set to "0" or containing errors the LAPC entity shall discard it. If the peer 
finds errors in the I_frame, response shall not be generated. In both cases timer P<DL.07> shall expire. An action shall 
be taken according to EN 300 175-4 [4], clause 9.2.3.1. 



11.4.1.2.2 



Receipt of a request for linl< release 



If DL_RELEASE-req primitive is received timer P<DL.07> shall be stopped. Class A link release procedure shall be 
performed (see clause 9.3). 



11.4.1.2.3 



Receipt of an indication for a connection release 



Timer P<DL.07> shall be stopped, all outstanding data shall be discarded, and, the NWK layer shall be informed for the 
MAC failure by DL_RELEASE-ind primitive. 

1 1 .4.2 Class A Acknowledged Information transfer 

The procedure shall be performed as defined in EN 300 175-4 [4], clauses 9.2.3.2 to 9.2.3.6. The following text together 
with the associated clauses define the mandatory requirements with regard to the present document. 

The following cases, depending on the frame which confirms the reception of the frame-request, shall be supported: 

• acknowledgement with an I_frame; 

• acknowledgement with an RR_frame. 
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1 1 .4.2.1 Acknowledgement with an l_frame 



PT 



FT 



V(S) 


V(R) 


V(A) 


X 


Y 


X 


X+1 


Y 


X 


X+1 


Y+1 


x+1 



I frame 



I frame 



V(S) 


V(R) 


V(A) 


Y 


X 


Y 


Y 


X+1 


Y 


Y+1 


x+1 


Y 



NOTE 1 : During the calculation of the variable's values the assumptions have been made that the IJrame sent by 
PT is not used for acknowledgement of previous received l_frames and, both frames are not 
re-transmission. 

NOTE 2: A Class A acknowledged information transfer procedure is considered as successful for the Initiator when 
in case N{S) is sent and N(R) is received the next equation is valid: (N{S)+1)mod2=N(R). 

NOTE 3: The IJrame sent by the FT is assumed to be acknowledged as well (not indicated in the figure). 

NOTE 4: The case when FT initiates differs only in the notations. 

Figure 58: Class A acknowledge information transfer by Iframe, PT initiated 
Table 47: Values used within the l-Frame sent by the PT(FT) 



Field 


Parameter within 
the field 


Standard values within 
the field/parameter 


Normative action/comment 


«Address-field» 








<NLF> 







<LLN> 


1 


Class A operation 


<SAPI> 





Connection oriented 


<C/R> 





From PT 




1 


From FT 


<RES> 


1 




«Control-field» 








<N(R)> 


=V(R) 


In 1 frame transmitter 


<P> 





Ignore 


<N(S)> 


=V(S) 


In 1 frame transmitter 


«Length-indicator- 
field» 








<Li> 


1..63 


Higher layer info length 


<M> 


All 




<N> 


1 


No extended length field. If "0" the frame 
may be discarded 


«lnformation field» 




All relevant 


Higher layer information 


«Fill field» 




11110000B 


Ignore. to 4 such octets may be included 
in case for the Cg logical channel 


«Checksum field1» 




All 




«Checksum field2» 




All 
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1 1 .4.2.2 Acknowledgement with a RR_frame 



PT 



FT 



V(S) 


V(R) 


V(A) 


X 


Y 


X 


X+1 


Y 


X 


X+1 


Y 


x+1 



I frame 



RR frame 



V(S) 


V(R) 


V(A) 


Y 


X 


Y 


Y 


X+1 


Y 



NOTE 1 : During the calculation of the variable's values an assumption has been made that the IJrame sent by PT 
is not used for acknowledgement of previous received l_frames and is not a re-transmission. 

NOTE 2: A Class A acknowledged information transfer procedure is considered as successful for the Initiator when 
in case N{S) is sent and N(R) is received the next equation is valid: (N{S)+1)mod2=N(R). 

NOTE 3: The case when FT initiates differs only in the notations. 

Figure 59: Class A acknowledge information transfer by RRframe 

The values used within the {I-Frame} shall be the same as in the case Acknowledgement with an I_frame, 
(see table 47). 

Table 48: Values used within the {RR-Frame} S-format message 



Field 


Parameter within 
the field 


Standard values within 
the field/parameter 


Normative action/comment 


«Address-field» 








<NLF> 







<LLN> 


1 


Class A operation 


<SAPI> 





Connection oriented 


<C/R> 





From FT 




1 


From PT 


<RES> 


1 




«Control-field» 








<N(R)> 


= V(R) 


In RR-frame transmitter 


<P/F> 





Ignore 


<SS> 







<***> 


1 


Constant 


«Length-indicator- 
field» 








<Li> 





No higher layer information 


<M> 







<N> 


1 


No extended length field. If "0" the frame 
may be discarded 


«Checksum field1» 




All 




«Checksum field2» 




All 





1 1 .4.2.3 Class A acknowledged information transfer with segment reassemble 

If procedure 1 1 .4.5 "Handling of NWK layer messages longer than 63 octets" is not supported the following provisions 
shall apply: 

If an implementation supporting longer messages wants to access an implementation which does not support 
segmentation, the last shall act as follows: 

• acknowledge the receipt of each error free, in sequence segment; 
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• do not store any segment after the first; 

• deliver to its own NWK layer only the first segment. 

1 1 .4.2.4 Associated procedures 



11.4.2.4.1 

DL.04>: 

value: 

start: 

stop: 



Timer <DL.04> management 

re transmission timer; 

refer to EN 300 175-4 [4], annex A; 

a I frame is transmitted; 



on receipt of: an acknowledgement for that frame; a DL_RELEASE-req primitive indicating 
"abnormal"; a MAC_DIS-ind primitive. 



1 1 .4.2.4.2 Re-transmission counter management 

Refer to clause 11.4.1.1.2. 

1 1 .4.2.4.3 Multiple frame operation variables management 

Refer to clause 11.4.1.1.3. 

1 1 .4.2.5 Exceptional cases 
11.4.2.5.1 Timer <DL.04> expiry 

Refer to EN 300 175-4 [4], clause 9.2.3.6. 

An errored or erroneous I-frame shall be discarded and therefore shall not generate peer response. 

An errored or erroneous frame-acknowledgement shall be discarded and timer <DL.04> shall not be stopped. 



PI 



V(S) 



X 



X+1 



V(R) 



Y 



Y 



V(A) 




FT 



I frame 



I frame 



Note 1 









V(S) 


V(R) 


V(A) 


► 
► 


Y 


X 


Y 



NOTE 1 : The l_frame is re-transmitted only if N250<max. value. 

NOTE 2: During the calculation of the variable's values an assumption has been made that the IJrames sent are 
not used for acknowledgement of previous received l_frames and the first one is not a re-transmission. 
NOTE 3: The case when FT initiates differs only in the notations. 
NOTE 4: The contents of the retranslated frame will be exactly the same as the first one. 

Figure 60: Timer <DL.04> expiry 

The values used within the {I-Frame} shall be the same as in the case acknowledgement with an I_frame (see table 47). 
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1 1 .4.2.5.2 Receipt of a request for link release 

On receipt of a DL_RELEASE-req after an I-frame has been transmitted timer <DL.04> shall be stopped and class A 
link release procedure (see clause 9.3) shall be performed. 

1 1 .4.2.5.3 Receipt of an indication for a connection release 

On receipt of an indication from the MAC layer for a release meaning either a bearer release started by the MAC layer 
or a bearer release resulting from a link release initiated by the peer, the timer <DL.04> shall be stopped and class A 
Link release procedure (see clause 9.3) shall be performed. 

1 1 .4.2.5.4 DLC wants to make a connection handover 

See class A basic connection handover procedure given in clause 9.7. 

11.4.3 Class A link release 

The procedure shall be performed as defined in EN 300 175-4 [4], clauses 9.2.3.7, 9.2.7.1.2, 10.2.2, and 10.4.1, 
EN 300 175-3 [3], clause 8.1.6, and EN 300 175-5 [5], clause 17.9. The following text together with the associated 
clauses define the mandatory requirements with regard to the present document. 

The procedure for Class A link release is initiated on receipt of a DL_RELEASE-req primitive (see clauses 8.37 
and 8.38) or a MAC_DIS-ind primitive. 

On receipt of a MAC_DIS-ind primitive DLC shall release the link. 

A link release procedure is qualified as "normal" if no outstanding I-frames or outstanding DL_DATA-req primitives 
have been discarded before the link has been released. 

Even if in the DL_RELEASE-req primitive a "normal" link release has been requested, the DLC layer might be unable 
to process all outstanding data. If any outstanding I-frames or DL_DATA-req primitives were or have to be discarded 
the release is qualified as "abnormal" and the resulting "abnormal" release mode shall be indicated in the 
DL_RELEASE-cfm and DL_RELEASE-ind primitives respectively. 

1 1 .4.3.1 Associated procedures 

1 1 .4.3.1 .1 LLME U-plane release 

The procedure shall be performed as defined in EN 300 175-4 [4], clause 10.4.2. 

1 1 .4.3.1 .2 LLME release a MAC connection 

The procedure shall be performed as defined in of EN 300 175-4 [4], clause 10.2 and EN 300 175-3 [3], clause 8.1.6. 

1 1 .4.4 Class A link re-establishment 

The procedure shall be performed as defined in of EN 300 175-4 [4], clause 9.2.3.8 and EN 300 175-5 [5], clause 17.8. 
The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

A class A link may be re-established at any time using the procedure for class A link establishment, (see clause 1 1.4.1). 
All outstanding DL_DATA primitives and I-frames shall be discarded, and all link variables shall be reset. 

Alternatively an implementation is permitted to release the link after receipt of an I-frame with NLF flag set to "1". 

A link shall not be re-established whilst in the "RELEASE-PENDING" state, see EN 300 175-5 [5], clause 14.2.7. 
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1 1 .4.5 Handling of NWK layer messages longer than 63 octets 

Both PT and FT shall be able to handle NWK layer messages longer than 63 octets. Longer than 63 octets messages 
shall be segmented at DLC sending side and re-assembled in DLC receiving side as specified in EN 300 175-4 [4], 
clause 7.7.2. 

1 1 .5 U-plane frame transmission procedures 
1 1 .5.1 DLC U-plane transmission Class 1 

11.5.1.1 General 

The general provisions given in EN 300 175-4 [4], clause 14.3.1 and clause 14.3.3 shall be followed. 

1 1 .5.1 .2 Sending side procedure 

The procedure shall be performed as defined in EN 300 175-4 [4], clause 14.3.3.1. 

1 1 .5.1 .3 Receiving side procedure 

The procedure shall be performed as defined in EN 300 175-4 [4], clause 14.3.3.2 with the following specific 
provisions: 

• The value of timer L(R) shall be set as equal to the MAC packet lifetime. 

• Timer L(R) shall be understood as running with the absolute TDMA frame counter. This timer shall not be 
stopped if the connection is suspended. 

11 .6 Lc frame delimiting and sequencing service 

11 .6.1 Cs channel fragmentation and recombination 

The procedure shall be performed as defined in EN 300 175-4 [4], clauses 6.1.2, 6.1.3, 6.1.4 and 6.1.4.2. The following 
text together with the associated clauses defines the mandatory requirements with regard to the present document. 

The complete frame shall be fragmented into 5 octet fragments. 

1 1 .6.2 Cf channel fragmentation and recombination 

The Cp channel shall be operated according to the procedures defined in EN 300 175-4 [4], clauses 6.1.2, 6.1.3, 6.1.4 

and 6.1.4.1. The following text together with the associated clauses defines the mandatory requirements with regard to 
the present document. 

The complete frame shall be fragmented into 8 octet fragments. 

1 1 .6.3 Selection of logical channels (Cs and Cf) 

The selection of the Cp instead of the Cg channel for Lc operation, shall be done according to the conditions defined in 

EN 300 175-4 [4], clause 10.2.5. 

If both sides have indicated that they support Cp channel (see 10.3.2.2.1 for the FT and 12.3 for the PT) all C-plane 
transmission shall take place on the Cp channel. 



£75/ 



138 



ETSI TS 102 939-1 VI. 1.1 (2013-04) 



1 1 .7 Broadcast Lb service 



11 .7.1 Normal broadcast 

The procedure shall be performed as defined in EN 300 175-4 [4], clauses 6.2.1, 8.3.3.1, 9.4.1.1 and 9.4.1.2 and 
EN 300 175-3 [3], clause 8.2.1. The following text together with the associated clauses defines the mandatory 
requirements with regard to the present document. 

Short frame format (frame length = 3) and full frame format (frame length = 5) are required to be supported. 



PT 



FT 




DL BROADCAST-ind 



DLC 



MAC PAGE-ind 



I 



MAC 




MAC_PAGE-req 



MAC 



Figure 61 : Normal broadcast 



Table 49: Information used within the DLBROADCAST-req primitive 



Parameter 


Information within the parameter 


Normative action/comment 


« Cluster address list » 


All cluster/an integer 




« Message unit length » 


3, 5 octets 


Short and full frame format are required 
to be supported. (It is assumed that the 
RFP will support some NG-DECT service 
that may use full format paging) 


« IVlessage unit » 


From the NWK layer 





Table 50: Information used within the MAC_PAGE-req primitive 



Parameter 


Information within the parameter 


Normative action/comment 


« cluster ID » 


All clusters/an integer 




« page type » 


Normal 


"fast" (LCE paging) is not required to be 
supported 


« length of page field » 


0, 20 or 36 


zero length, short and full paging formats 


« long flag » 


N/A 


Long paging formats (length of page field 
> 36) does not need to be supported. 


« SDU » 


The data from the « Message unit » 
received in the DL_BROADCAST-req 
primitive. 
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Table 51 : Information used within the MAC_PAGE-ind primitive 



Parameter 


Information within the parameter 


Normative action/comment 


« length of page field » 


20 or 36 




« long flag » 


N/A 


Long paging formats (length of page field 
> 36) does not need to be supported. 


« SDU » 


The LCE page SDU 





Table 52: Information used within the DLBROADCAST-ind primitive 



Parameter 


Information within the parameter 


Normative action/comment 


« Message unit length » 


3, 5 octets 


Short and full formats 


« IVIessage unit » 


The data from the « SDU » from 
the IVIAC PAGE-ind primitive. 





11.8 LU13 Enhanced Frame RELay service with CRC (EFREL- 
CRC) 

The procedure shall be performed as defined in EN 300 175-4 [4], clause 11.15. The following text together with the 
associated clauses defines the mandatory requirements with regard to the present document. 

The packet received from the U-plane application layer shall be the LU13 SDU. 

A 32 bit CRC shall be added at the end of the LU13 SDU as described in EN 300 175-4 [4], clause 11.15.2, second 
bullet. The 32 bit CRC shall be identical to the B-CRC defined in EN 300 175-3 [3], clause 6.2.5.5. 

Only the 32 bit CRC option defined in EN 300 175-4 [4] is supported by the present document. 

The reverse procedure shall be done at the receiving side. 

In case of wrong CRC decoding, the packet shall be discarded and an error notification shall be sent to higher layer. 

The standard delivery mode (see LUlO description) shall be used. 

The maximum LU13 SDU size that shall be supported is defined in clause B.2.1. 

The maximum SDU size in use at a given time may be configured by means of C-plane procedures. See clause B.2.1. 

All provisions applicable to the LUlO processing, underlying layers and the transport protocol are given in Service 
[ULE1-D.3]. 

Only one instance of LU13 shall be supported between the same PT-FT pair: 

• The support of multiple instances of LU13 is for further study. 

1 1 .9 Encryption switching 

11 .9.1 IVIAC layer encryption switching 

This procedure refers to the activation or deactivation of the MAC layer encryption (see for instance EN 300 175-3 [3], 
clause 6.2.3). For activation of the CCM encryption, see clause 11.9.2. 

The procedure shall be performed as defined in EN 300 175-4 [4], clause 10.6, EN 300 175-7 [7], clauses 6.5.3 and 
6.4.6 and EN 300 175-3 [3], clause 6.2.3. The following text together with the associated clauses defines the mandatory 
requirements with regard to the present document. 

The procedure for encryption deactivation is not required to be supported since a new connection is always established 
in clear mode. Therefore any connection or link release implies encryption deactivation. 

The encryption deactivation is mandatory only if service [ULEl-D. 1 1] is supported. 
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1 1 .9.1 .1 Associated procedure 

11 .9.1 .1 .1 Providing Encryption key to the MAC layer 

On receipt of the DCK in a DL-ENC_KEY-req primitive the DLC shall transmit it to the MAC layer. 

A record shall be kept for the active (the one used for the current encryption) DCK for use in case of connection 
handover. 

11 .9.1 .2 Exceptional cases 

11.9.1.2.1 Encryption fails 

An encryption attempt which fails means the desired "Crypted" mode is not achieved. If the MAC fails to switch from 
clear to encrypted mode the connection is released and the DLC layer is informed by a MAC_DIS-ind primitive. At the 
peer side this indication shall arrive as a result of the connection release. 

1 1 .9.1 .2.2 Connection handover of ciphered connections 

Connection handover is for further study and not supported by this revision of the present document. 

1 1 .9.2 CCM encryption switching 

When a DLC LU14 instance (DLC layer U-plane service with CCM) is created, a valid derived cipher key stored under 
the cipher key nr. associated to CCM should exist. Such derived cipher key has had to be created using a MM process: 

• The key shall be automatically retrieved from NWK layer MM and transferred to the CCM engine associated 
to the LU14 instance for use as encryption key. 

• If the key is not available, the LU14 instance cannot be created. 

LU14 hnks shall be CCM encrypted from the first SDU. 

When the DLC service operates in both ways (consisting either on a bi-directional link or two unidirectional links), the 
same key shall be used in both directions. 

There is not a procedure for CCM encryption de-activation. 

There is not a procedure for CCM re-keying. If this is required, the link may be dropped and a new one may be set up. 

11.10 CCM/AES encryption 

11.10.1 CCM Autinenticated Encryption 

The procedure shall be performed as described in EN 300 175-7 [7], clause 6.6.2. 

The Initialization Vector shall be computed as described in EN 300 175-7 [7], clause 6.6.2.3. 

11.10.2 CCM activation at Virtual Call setup 

The CCM Authenticated Encryption shall start automatically when a LU14 DLC link is created. This happens when a 
Virtual call invoking this service is setup or resumed at NWK layer. 

All LU14 U-plane transfer shall be CCM encrypted starting by the first SDU. 

An unused Derived Cipher Key (DCK) generated by a PT authentication process and identified as a CCM Key, should 
exist before the creation of a LU14 instance. Otherwise the link setup and the associated Virtual Call setup should fail. 

• The provisions given in EN 300 175-7 [7], clause 6.3.7.1 shall apply in this case. 
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• CCM sequence number shall be handled as described in EN 300 175-7 [7], clause 6.6.2.4. Both, the CCM 
sequence number and the DLC sending sequence number shall be set to "0" at the activation of the LU14 
instance after the NWK layer Virtual Call setup or resume procedure. 

CCM Sequence resetting and re-keying procedures without creating a new link are for further study. 

11.10.3 Cipher keys for CCM 

Keys used by shall be Derived Cipher Keys (DCK) of 128 bits and are generated by a PT authentication process, as 
described in EN 300 175-7 [7], clause 6.2.3. 

The Derived Key to be used for CCM shall use the <Cipher Key nr> = "9". This value shall be used in IE «Auth- 
type» and «Cipher-Info» associated to CCM keys. 

The provisions for single use of the Keys given in EN 300 175-7 [7], clause 6.2.3.1 shall apply. 



1 2 NWK layer procedures 

12.1 Simplified NWK layer control procedures for ULE phase 1 

In ULE phase 1, a simplified CC control model is used. Such model is based on the concept of a PVC (Permanent 
Virtual Circuit) controllable by means of Service Change operations. 

12.1.1 General pre-requisites 

The CC transaction value number 5, FT initiated, is reserved and shall not be used by any other service. This transaction 
number represents the ULE PVC. 

ULE PT and FT shall support a DECT MAC service call with capacity to carry C-plane NWK messages. However, it 
does not need to be necessarily the same MAC connection that carries the ULE traffic. Network messages to control 
ULE PVC may be carried over any circuit mode MAC connection, such as the one used to set up a Service Call. 

12.1.2 Creation of the ULE PVC and states 

When a ULE phase 1 PP is registered in a phase 1 RFP, a CC transaction with transaction value 5 (FT initiated), is 
automatically created without any CC operation. 

Such CC transaction may only have two states: 

• Connected and NWK suspended 

• Connected and NWK resumed 

NOTE: The states "NWK suspended" and "NWK resumed" refers to the NWK layer suspend and resume 

mechanism (as described in EN 300 175-5 [5], clause 9.6.4) and should not be confused with the MAC 
suspension and resume. Since both types of operations are used in the present document, the terms "NWK 
suspend" or "NWK resume" are used when referring to the NWK operations, except when it can be easily 
inferred from the context. 

When the state is "NWK suspended", there is neither link nor MBC associated to the CC transaction. 

When the state is "NWK resumed", there is a DLC LU link and a MAC MBC associated to the CC transaction. NWK 
resumed stated does not imply physical layer activity since the MAC MBC may be either MAC suspended or MAC 
resumed. 

12.1.2.1 State diagram 

Figure 62 shows the two possible states of the transaction and the possible operations. 
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Mobility Management 

DCKforCCM 



Consumes a CCM DCK from MM (if LU14) 

CC Service cinange "resume" 



CC Service change 
"otiner" 




CC Service cinange 
"otiner" 



CC Service change "suspend" 

Figure 62: States and allowed transitions of the CC transaction 

The ULE transaction only supports the CC operation "Service Change" by means of the message{CC Service Change} 
and its two possible replies {CC-Service Accept} and {CC-Service Reject}. 

Any other CC message over this transaction shall be ignored. 

Only the following three operations are possible: 

• Service Change "NWK resume" 

• Service change "NWK suspend" 

• Service change "other" 



12.1.2.2 



Creation of the transaction 



The transaction is always created (at registration) with the state NWK suspended. Transition between states is done by 
means of Service change CC operations as described in clause 12.1.3. 

When the transaction is created, the default parameters given in clause 12.1.3.8 shall apply. 

NOTE: The normal state of the transaction is normal ULE operation is NWK resumed. 

12.1.3 Allowed CC Operations over the ULE transaction 

The ULE transaction only supports the CC operation "Service Change" by means of the message {CC Service Change} 
and its two possible replies {CC-Service Accept} and {CC-Service Reject}. 

Any other CC message over this transaction shall be ignored. 

Only the following three operations are possible: 

• Service Change "NWK resume" 

• Service change "NWK suspend" 

• Service change "other" 

Each operation shall use the message {CC Service Change} and one of its possible replies {CC-Service Accept} (if 
successful) and {CC-Service Reject} (if unsuccessful). 

The operations Service Change "NWK resume" and Service Change "NWK suspend" change the state of the CC 
transaction between the two possible states. They may also transfer parameters. 

The operation Service Change "other" does not change the state and only transfers parameters. 
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1 2.1 .3.1 Service Change "NWK resume" 

This operation changes the state of the CC transaction from "NWK suspended" to "NWK resumed". 

This operation should always be invoked for any ULE activation (since the ULE CC transaction is always created in 
suspended state). 

12.1.3.1.1 Pre-requisite: 

The following pre-requisite applies if the required DLC service is LU14: 

• A suitable (unused) Derived Cipher key for CCM shall exist before the completion of the CC Service Change 
operation (i.e. before the responding side sends the {CC-Service- Accept} response). Such Derived Cipher Key 
will be the key for LU14 and is consumed in the operation. 

In the case of FP-initiated "NWK resume", the FP shall ensure that a valid cipher key exists before sending the {CC- 
Service-Request } message. 

In the case of PP -initiated "NWK resume", the FP shall ensure that a valid cipher key exists before responding with the 
{CC-Service-Accept} message. If required, the FP shall generate the Derived Cipher Key for CCM by invoking of the 
Authenticate PP procedure (see EN 300 444 (GAP) [9], clauses 8.24 and 8.45.7). 

If the CCM Derived Cipher key does not exist and can not be generated, the resume operation shall fail (the response 
{CC-Service Reject} shall be used) and the state shall remain as "NWK suspended". 

12.1.3.1.2 Coding of \.he operation messages 

This operation is coded as follows: 

• Initiating message {CC Service Change} 

• Possible replies {CC-Service Accept} and {CC-Service Reject} 

• Transaction value : 5, FT originated 

• The lEs « SERVICE-CHANGE-INFO » and « CONNECTION-IDENTITY » shall be included and 
coded as follows 

Table 53: Mandatory lEs and their values used within the {CC-SERVICE-CHANGE} and 

{CC-SERVICE-ACCEPT} message 



Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 


Protocol Discriminator 
Transaction Identifier 




0011 


Call control 


Flag 


0-1 


The transaction is assumed to be 
FT originated 


Transaction value 


101 


"5" 


« SERVICE-CHANGE- 
INFO » 








< Ext3 > 


1 


Octet 3a not used 


< Coding standard > 


00 


DECT standard coding. 


<M> 


0/1 


Initiating/Receiving side is master. 


< Change Mode > 


1001 


"Resume" 


<A> 


000 


Not Applicable 




<R> 





Do not reset state variables, this 
parameter may be ignored 


<B> 


000 


Not Applicable 


« CONNECTION- 
IDENTITY » 










< U Plane link identity > 





unnumbered U-plane link 




< Connection identity > 


1111 


ECN = 7 



£75/ 



144 ETSI TS 102 939-1 VI. 1.1 (2013-04) 

In addition to the two mandatory lEs, the message may also carry any of the lEs allowed in clause 12.1.3.4. 

12.1 .3.1 .3 Actions after a successfully CC Service Change "NWK resume" operation 

12.1.3.1.2.1 DLC layer 

After a successfully CC Service Change "NWK resume" operation, a DLC U-plane link (LU) shall be created at both 
peers. The LU shall be LU13 or LU14 according to the parameter currently set for the transaction. Since the default 
parameter is LU14 (see clause 12.1.3.5) the LU shall be LU14 unless the LU parameter has been changed by means of a 
previous or a simultaneous insertion of the IE «Call attributes». 

The DLC and CCM sequence numbers shall be initialized to "0" as indicated in EN 300 175-4 [4], clause 11.16.2.5. 

The Derived Cipher key for CCM generated by the MM (which should exist) shall be used in the LU14 (and is 
consumed in the operation). 

12.1.3.1.2.2 MACIayer 

A MAC MBC with ECN = 7 and suitable for expedited operations shall be created or associated to the transaction. 

a) If such MBC (ECN = 7) exists, it shall be associated to the transaction with its existing MAC parameters. 

b) If such MBC (ECN = 7) does not exist, it is created at both sides with the default parameters given in 
clause 12.1.3.8, without the exchange of any MAC message. 

The mechanism described as case b) is named "logical connection setup - implicit procedure" (see also clause 10.7.1.3). 

NOTE: This is the normal MBC creation mechanism in ULE phase 1 . 

1 2.1 .3.2 Service Change "NWK suspend" 

This operation changes the state of the CC transaction from "NWK resumed" to "NWK suspended". 
This operation may be invoked only if needed. 

NOTE: A possible reason for the use of the "NWK suspend" operation is the need to reset the DLC link. 

12.1.3.2.1 Pre-requisite: 
Not apphcable. 

1 2.1 .3.2.2 Coding of the operation messages 
This operation is coded as follows: 

• Initiating message {CC Service Change} 

Possible replies {CC-Service Accept} and {CC-Service Reject} 

Transaction value : 5, FT originated 

The lEs « SERVICE-CHANGE-INFO » shall be included and coded as follows 



• 
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Table 54: Mandatory lEs and their values used within the {CC-SERVICE-CHANGE} and 

{CC-SERVICE-ACCEPT} message 



Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 


Protocol Discriminator 
Transaction Identifier 




0011 


Call control 


Flag 


0-1 


The transaction is assumed to be 
FT originated 


Transaction value 


101 


"5" 


« SERVICE-CHANGE- 
INFO » 








< Ext3 > 


1 


Octet 3a not used 


< Coding standard > 


00 


DECT standard coding. 


<M> 


0/1 


Initiating/Receiving side is master. 


< Change Mode > 


1000 


"Suspend" 


<A> 


000 


Not Applicable 


<R> 





Do not reset state variables, this 
parameter may be ignored 


<B> 


000 


Not Applicable 



In addition to the mandatory lEs, the message may also carry any of the lEs allowed in clause 12.1.3.4. 

NOTE: When additional lEs are exchanged, and the operation is successful, the parameters carried in these lEs 
are immediately set into the transaction, even if the resulting state is "NWK suspended". Some of such 
parameters will only be used after a subsequent resume. 



12.1.3.2.3 



Actions after a successful CC Service Change "NWK suspend" operation 



12.1.3.2.3.1 DLC layer 
DLC LU entity is released. 

12.1.3.2.3.2 MAC layer 

Case A: If the CC message was carried by a different MBC to the one associated to the transaction. 

• The CC operation is completed and the MAC MBC associated to the transaction (with ECN = 7) is released at 
both peers without any further signalling operation. 

NOTE: This is the normal intended operation in ULE phase 1 . 

Case B: If the CC message was carried by the same MBC that is associated to the transaction. 

• The CC operation is completed, and then the MAC bearer is released using MAC normal release (not 
expedited) procedures. 

1 2.1 .3.3 Service Change "other" 

At any state, it is possible to perform service change operations that are neither suspend nor resume. They are used to 
configure parameters of the P VC. The transaction state remains unchanged. 

12.1.3.3.1 Pre-requisite: 

Not applicable. 

1 2.1 .3.3.2 Coding of the operation messages 
This operation is coded as follows: 

• Initiating message {CC Service Change} 
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Possible replies {CC-Service Accept} and {CC-Service Reject}. 

Transaction value : 5, FT originated 

The IBs « SERVICE-CHANGE-INFO » shall be included and coded as follows 

Table 55: Mandatory lEs and their values used within the {CC-SERVICE-CHANGE} and 

{CC-SERVICE-ACCEPT} message 



Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 


Protocol Discriminator 
Transaction Identifier 




0011 


Call control 


Flag 


0-1 


The transaction is assumed to be 
FT originated 


Transaction value 


101 


"5" 


« SERVICE-CHANGE- 
INFO » 








< Ext3 > 


1 


Octet 3a not used 


< Coding standard > 


00 


DECT standard coding 


<M> 


0/1 


Initiating/Receiving side is master 


< Change Mode > 


0000 


"none" 

The "none" value is used when 

there is no state change 


<A> 


000 


Not Applicable 


<R> 





Do not reset state variables, this 
parameter may be ignored 


<B> 


000 


Not Applicable 



In addition to the mandatory lEs, the message may also carry any of the lEs allowed in clause 12.1.3.4. 

1 2.1 .3.4 Allowed parameters in any service change operation 

The following parameters may be inserted in any service change operation. In all cases they will be transmitted in 
addition to the mandatory lEs. 

All lEs shall always be transmitted over the air in the standard DECT order, as indicated in EN 300 175-5 [5], 
clause 6.3.1. 

For FT initiated operations, the PT shall repeat the parameters sent by the FT. If the FT is trying to set an optional value 
of a parameter that the PT does not support, it is allowed for the PT to reject the operation. The release reason IE with 
the code '06'H (service not implemented) shall be inserted in the {Service Reject} message. 

For PT initiated operations, the parameters sent in the PT => FT direction have the nature of suggestion. The FT has the 
choice to reject the operation and start an FT initiated Service Change with its own parameters. The release reason IE 
may be inserted in the {Service Reject} message. 

If the « ULE-MAC-CONFIGURATION-INFO » IE is used in a request message sent by the PT, it shall be coded 
with control = and no descriptors shall be sent. 

After a successfully operation, the parameters carried in these lEs are immediately set into the transaction, even if the 
resulting state is "NWK suspended". However some of such parameters will only be used after a subsequent resume. 

Before or in absence of any Service change operation changing parameters, the default parameters given in 
clause 12.1.3.5 shall apply. 
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Table 56: Optional parameters that may be used in the {CC-SERVICE-CHANGE} and 
{CC-SERVICE-ACCEPT} message in any CC Service change operation 



Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 


« ULE-MAC- 
CONFIGURATION-INFO » 


Control 


0-1 


0=de-allocates all channels, 
1= append new channel 
Control value =0 shall also be used 
in the PT=>FT message 


Paging descriptors 


All 


All values may be used. The 
number of combinable paging 
descriptors is limited to 2 
Paging descriptors shall be 
inserted only in the message sent 
in FT=> PT direction 


« TRANSIT-DELAY » 








Overall DECT system 
maximum Delay 


Any 


Overall DECT system maximum 
delay is not used and shall be 
ignored. It is recommended to code 
it with the same value as next 
parameter" overall MAC layer 
maximum lifetime" 


overall MAC layer 
maximum lifetime 


1-1 008 frames 


Codes the overall MAC layer 
maximum lifetime 


« WINDOW-SIZE » 








Window size value 
(PT => FT, used for 
both directions) 


8-128 


The same window size is used in 

both directions. 

All other parameters in the IE are 

not used 

Only values 8, 1 6 and 32 are 

mandatory to support. All others 

are optional 


« IWU-ATTRIBUTES » 


Coding Standard 


'01 'B 


Profile defined coding 


Profile 


'10000'B 


ULE profile 


Negotiation indicator 


'100'B 


Exchanged parameter negotiation 


Profile subtype 


'OOOO'B 


ULE Part 1 transparent 
Interworking 


IWU function at FP 


'0000001 'B 


transparent routing 


ULE Application 
Protocol Identifier 


'OOOOOOO'B 
'0000001 'B 
'1 xxxxxx'B 


undefined protocol 

ULE Functional application protocol 

#1 

Proprietary ULE protocols 


ULE Application 
Protocol Version 


all 


Coding specified by the application 
protocol 


IVIaximum IVITU/SDU 
size 


8 - 65532 octets (coded 
as 16383) 


Maximum size of the SDU (and 
MTU) All values above 500 are 
optional to support 


EMC 


all 


EMC code for discriminating 
proprietary protocols 
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Information element 


Field within the 
information element 


Standard values within 

the field/information 

element 


Normative action/comment 


« CALL-ATTRIBUTES » 


Coding Standard 





DECT standard coding 


NWK layer attributes 


'0100'B(ULE parti) 


ULE part 1 


C-plane class 


'010'B, (Class A link), or 
'111'B (no C-plane) 


No C-plane mandatory (see note) 
Class A link, optional 


C-Plane routing 


'OOOO'B (Cs only),, 

'0010'BCf (preferred), 

'1 11 1'B (no C-plane 

routing) 


No C-plane mandatory (see note). 
Cs and Cf optional 


U-Plane symmetry 


1 


Symmetric 


LU identification 


'0001101'B(LU13), 
'0001110'B(LU14) 


LU14 mandatory, LU13 optional 
(except for markets where LU14 is 
not allowed) 


U-Plane Class 


'010'B 


Class 1 


FU-Type symmetry 


1 


Symmetric 


U-Plane frame type 
and options (if LU is 
LU13) 


'1001'B(FU10a/d, CRC 
32 bit) 


FUlOa/FUIOd CRC-32 bit (only 
combination supported) 


U-Plane frame type 
and options (if LU is 
LU14) 


'1001'B(FU10a/d) 


FUlOa/FUIOd (only combination 
supported) 



NOTE: No C-plane refers to the case when the MAC connection associated to the PVC does not have the 

capabiHty to transport C-plane higher layer messages and does not have its own DLC C-plane entity. In 
such a case, the C-plane higher layer messages may be transported over other MAC connections (that 
may be associated to other CC transactions). This is the normal mode in ULE phase 1. 

1 2.1 .3.5 Default parameters 

The ULE PVC transactions are created with the following default parameters, which shall apply unless changed by any 
Service Change operation. 

Table 57: Default parameters for ULE PVC transactions 



Information element 


Field within the 
information element 


Default values 


Normative action/comment 


« ULE-MAC- 
CONFIGURATION-INFO » 








Paging descriptors 


No paging descriptor 
allocated 




« TRANSIT-DELAY » 








Overall DECT system 
maximum Delay 


Not applicable 




overall MAC layer 
maximum lifetime 


7 


7 frames = 70 ms. 


« WINDOW-SIZE » 








Window size value 
(PT => FT, used for 
both directions) 


16 


The same window size is used in 
both directions. All other 
parameters in the IE are not used 
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Information element 


Field within the 
information element 


Default values 


Normative action/comment 


« IWU-ATTRIBUTES » 


Coding Standard 


'01 'B 


Profile defined coding 


Profile 


'10000'B 


ULE profile 


Negotiation indicator 


'100'B 


Exchanged parameter negotiation 


Profile subtype 


'OOOO'B 


ULE Part 1 transparent 
Interworking 


Reserved bits 


'OOOOOOO'B 


shall be coded to '0' 


ULE Application 
Protocol Identifier 


'OOOOOOO'B 


undefined protocol 


ULE Application 
Protocol Version 


'0' 


Coding specified by the application 
protocol 


IVlaximum MTU/SDU 
size 


32 octets (coded as 8) 


Maximum size of the SDU (and 
IVITU). Default value shall be 
understood as bidirectional 


« CALL-ATTRIBUTES » 


Coding Standard 





DECT standard coding 


NWK layer attributes 


'0100'B (ULE parti) 


ULE part 1 


C-plane class 


'111'B (no C-plane) 


No C-plane is the default value for 
ULE phase 1 


C-Plane routing 


"1111'B (no C-plane 
routing) 


No C-plane routing is the default 
value for ULE phase 1 


U-Plane symmetry 


1 


Symmetric 


LU identification 


'0001110'B (LU14) 


LU14 is the default value for ULE 
phase 1 


U-Plane Class 


'010'B 


Class 1 


FU-Type symmetry 


1 


Symmetric 


U-Plane frame type 
and options (if LU is 
LU14) 


'1001'B(FU10a/d) 


FUlOa/FUIOd (only combination 
supported) 



1 2.1 .3.6 Initiating part of the Service Change operations 

Service change operations may be initiated by any of the peers. 



12.1.3.6.1 



Rule for handling collisions 



In case of collision of PT initiated and FT initiated operations, the FT shall reject the colliding PT initiated operation. 
The release reason IE with the code 'OC'H (collision) shall be inserted in the {Service Reject} message. 

The PT shall continue processing the FT initiated operation. 

1 2.1 .3.7 Independence of other CC transactions. 

The standard DECT rules apply regarding the use of Service Change CC operations and MM states. 

Service change CC operations related to the ULE P VC (transaction 5 FT initiated) are orthogonal to the states of other 
CC transactions that may exist in the PT-FT pair. 

1 2.1 .3.8 Default MAC parameters for implicitly created MBC 

When a pair of MAC MBCs is created without exchange of MAC signalling, as result of the procedure described in 
clause 12.1.3.1.2.2, case b), the following default MAC parameters shall be used. 
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Table 58: Default MAC parameters in MBCs created without exchange of MAC messages after a 

Service Change Resume operation 



MAC parameter 


Default initial value 


comment 


Type of connection 


Advanced 




ECN 


7 




LBN 


Not applicable 


The MBC is always created in MAC 
suspended state 


Up/down/sm/ss 


'11'B 


Symmetric single bearer 


Ser type 


IpQR 


MAC IpQR error correct 


Max lifetime 


7 




Slot type 


Full 


Full slot 


Cf 





Cpnot used 


A-field modulation 


2-level 


2-level GFSK 


B+Z field modulation 


2-level 


2-level GFSK 



12.1 .3.9 Paging descriptors in suspend and resume states 

Paging descriptors for By paging configured by means of « ULE-MAC-CONFIGURATION-INFO » apply even in 
NWK suspend state. 

Paging commands received over B^ when the PP is in "NWK resumed" state trigger a MAC resume using expedited 
procedures as described in clause 10.10. 

Paging commands received over By when the PP is in "NWK suspended" state shall be understood as orders to set up 
the Service Call and performing a Service Change "resume" operation. 

NOTE: MM procedures may also be executed, if needed, in order to generate a fresh key for CCM. 

12.1.3.10 Negotiation rules 

The following negotiation rules apply when exchanging parameters via any CC Service Change operation: 
« ULE-MAC-CONFIGURATION-INFO » 

The descriptors are always set by the FT. 
« TRANSIT-DELAY », 

<Overall MAC layer maximum lifetimo 

The initiating side may propose a new value. The other side may accept it, or reply with the default value in the 
response message. 

« WINDOW-SIZE » 



The initiating side may propose a new value. The other side shall accept it if it is in the range 8-32. Otherwise it may 
reply with the default value in the response message. The value in the response message shall be the one to be used. 

« IWU-ATTRIBUTES » 

<ULE Application Protocol Identifier> 

FT shall accept any value proposed by the PT 
PT shall only accept values it really supports 
< ULE Application Protocol Version > 

Any value shall be accepted 
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< Maximum MTU/SDU size > 

FT shall accept any value proposed by the PT if it is < 500 octets. If the PT proposes a higher value and the FT does 
not support it, it may reply with 500 and this will be the used value. 

PT shall accept any value proposed by the FT that the PT may support. If this is not the case, the PT may reply with 
the highest value it may support (depending on the implemented application protocols). 

<EMC> 

Any value shall be accepted 
« CALL-ATTRIBUTES » 

< C-plane class >, < C-plane routing >, 

It is allowed to reply with the mandatory value (no C-plane), and this will be the value to be used. 

< LU identification > 

It is allowed to reply with the mandatory value (LU14), and this will be the value to be used. 

1 2.2 Other NWK layer procedures 
1 2.2.1 Service call setup 

The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 



12.2.1.1 



Prerequisites 



The service call shall be established only over a (circuit mode) basic MAC connection. The NWK messages associated 
to this call shall be routed over its own (basic connection) MBC. 



12.2.1.2 



Procedure 



The GAP outgoing call request procedure shall be used as defined in EN 300 444 [9], clause 8.2, with the following 
replacement to the {CC-SETUP} message. 

Table 59: Values used within the {CC-SETUP} message for service call 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Basic service» 








<Call class> 


'001 1'B 


ULE Service call setup 



1 2.2.2 Storing the Derived Cipher Key for CCM (DCK-CCM) 

This procedure is required by the DLC Service [ULE1-D.12] "CCM/AES encryption". It is related, but not exactly the 
same, to the procedure "Storing the Derived Cipher Key (DCK)" (clause 8.27 of EN 300 444 (GAP) [9]). 

In order to generate a Derived Cipher Key for CCM, the authentication of PT procedure of the feature [ULE1-N.3] 
("Authentication of the PP") is executed with the modification noted in table 60 to the {AUTHENTICATION- 
REQUEST} message. 

The procedure may be either Authentication of PP using DSAA (clause 8.24 of [9]) or Authentication of PP using 
DSAA2 (clause 8.45.7 of [9]). The strongest security is achieved with the Authentication of PP using DSAA2. 

This procedure may be executed using either DSAA or DSAA2 algorithms. The procedure for authentication of F*T 
shall be executed as described in clause 8.24 when DSAA is used or as described in clause 8.45.7 when DSAA2 is used. 
The strongest security is achieved with the Authentication of PP using DSAA2. 
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The authentication algorithm shall be the same in use for the execution of the FT authentication procedures. 
The following modification shall apply in the message {AUTHENTICATION-REQUEST} sent by the FT. 

Table 60: Replacement to {AUTHENTICATION-REQUEST} for storing the DCK for CCM (DCK-CCM) 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Auth-type» 








<UPC> 


1 


Store the new DCK 


<Cipher key number> 


9 


See EN 300 175-7 [7], clause 6.2.3 



For the other contents of the {AUTHENTICATION-REQUEST} message, refer to table 39 of EN 300 444 (GAP) [9] 
(clause 8.24) if DSAA is used or to table 82 of EN 300 444 [9] (clause 8.45.7) if DSAA2 is used. 

12.3 Terminal capabilities and FP broadcasts 
12.3.1 Terminal capability indication 

The PP shall be able to send the «Terminal capability» information element and the FP shall be able to receive it at 
least in {ACCESS-RIGHTS-REQUEST} and when location registration is supported in the {LOCATE-REQUEST}. 
The following text together with the associated clauses define the mandatory requirements with regard to the present 
document. 

Terminal capability indication shall be done as defined in clause 8.17 of EN 300 444 [9] (GAP) with the following 
content in the «Terminal capability» information element. 

Table 61 : Values used within the «TERMINAL CAPABILITY» information element 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal 
capability» 








<Slot type capability> 


"'xxx1xxx"B 


Full slot supported (all others optional) 


<Profile indicator_1> 


'xxxxxXx'B 
X = [0,1] 


GAP and/or PAP supported or not 
supported (see note 1 ) 


<Profile indicator_4> 


"xxxXxxx"B 
X = [0,1] 


Support or not support of Cp channel 
(see note 1) 


<Profile indicator_4> 


"xx1 xxxx"B 


IpQ services supported 


<Profile indicator_5> 


"xxxxxxV'B 


2-level modulation scheme supported 
(B+Z field) 


<Profile indicator_5> 


"xx1xxxx"B 


2-level modulation scheme supported 
(A field) 


<Profile indicator_6> 


"xXxxxx"B 
X = [0,1] 


PI with fast hopping radio or not (see 
note 1) 


<Profile indicator_7> 


"xxXxxxx"B 
X = [0,1] 


Support or no support of "Re-keying" 
and "default cipher key early 
encryption mechanism" (see notes 1 
and 2) 


<Profile indicator_7> 


"xxxxxXx"B 
X = [0,1] 


Support or no support of NG-DECT 
Part 1 : Wideband voice supported 
(TS 102 527-1 [1.6] and note 1) 


<Profile indicator_7> 


"xxxxXXx"B 
X = [0x,11] 


Support or no support of NG-DECT 
Part 3: Wideband voice supported 
(TS 102 527-3 [13] and note 1) 


<Profile indicator_9> 


"xxx1xx"B 


Support for DECT ULE phase 1 


DSAA2 (Octet 5) 


[0,1] 


Support (or not support) of the DSAA2 
(see EN 300 175-7 [7] and notes 1 
and 2) 


DSC2 (Octet 5) 


[0,1] 


Support (or not support) of the DSC2 
(see EN 300 175-7 [7] and note 1) 
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Information 
element 



Field within the 
information element 



Standard values within the 
field/information element 



Normative action/comment 



NOTE 1 : This bit is only set if the corresponding capability is supported. 

NOTE 2: This capability is assumed as the default value (see table 62) if the «TERI\/1INAL-CAPABILITY» 
information element is omitted. 



The capabilities in next able shall be assumed as default if the following fields in the «TERMINAL CAPABILITY» 
information element are not present. 

Table 62: Values assumed as terminal capabilities 



Information 
element 


Field within the 
information element 


Standard values within the 
field/information element 


Normative action/comment 


«Terminal 
capability» 








<Slot type capability> 


"'xxx1xxx"B 


Full slot supported 


<Profile indicator_1> 


'xxxxxOx'B 


GAP and/or PAP not supported 


<Profile indicator_4> 


"xxxOxxx"B 


No support of Op channel 


<Profile indicator 6> 


"xOxxxx"B 


PT without fast hopping radio 


<Profile indicator_7> 


"xxOxxxx"B 


No support of "Re-keying" and 
"default cipher key early encryption 
mechanism" 


<Profile indicator_7> 


"xxxxxOx"B 


No support of NG-DECT Part 1 : 
Wideband voice (TS 102 527-1 [i.6]) 


<Profile indicator_7> 


"xxxxOOx"B 


No support of NG-DECT Part 3: 
Extended Wideband voice 
(TS 102 527-3 [131) 


DSAA2 (Octet 5) 





No support of the DSAA2 
(see EN 300 175-7 [7]) 


DSC2 (Octet 5) 





No support of the DSC2 
(see EN 300 175-7 [7]) 



12.3.2 FP broadcasts 

NOTE: This clause defines only the NWK layer content in the FP broadcast. See also clause 10.3.2.2.1 which 
defines the MAC layer content. 

12.3.2.1 Higher layer information FP broadcast 

The FP and PT shall support the broadcast of Higher Layer capabilities as part of Qx MAC broadcast messages (see 
clause 10.3.2.2). 

The broadcast attributes are a small set of NWK layer and DLC layer capabilities (jointly known as "higher layer 
capabilities") that shall be broadcast regularly as part of the MAC layer broadcast service. See EN 300 175-5 [5], 
annex F. 

RFPs belonging to the same LA shall broadcast the same values of higher layer attributes (see EN 300 175-5 [5], 
annex F) at any given time. 

The PP shall be capable to read and interpret at least the following broadcast attributes codlings during locking 
procedure. In the locked state the PP may assume them as static. 

FP and PT shall support the following values of "Higher Layer capabilities" information attributes. 



£75/ 



154 



ETSI TS 102 939-1 VI. 1.1 (2013-04) 



12.3.2.1.1 



Higher layer information in standard FP broadcast (Qh = 3) 



The Higher Layer capabiHties Fixed Part Information field shall be used to indicate the support of the indicated features. 
Most bits are not specific of ULE part 1, but will be set in most RFPs due to the coexistence with voice services. 

Table 63: Higher layer information attributes in standard FP broadcast (Qh = 3) 



BIT Number 


Attribute 


Value 


Note 


032 > 


ADPCM/G.726 Voice service 


[0,1] 


If voice services are supported 


<a33> 


GAP and/or PAP basic speech 


[0,1] 


If voice services are supported 


<a36> 


DECT Standard Authentication 
(DSAA) required 


1 


IVIandatory to support 


037 > 


DECT Standard Cipher (DSC) 
supported 


1 


IVIandatory to support 


038 > 


Location registration supported 


1 


See location update procedure, clause 8.29 of 
EN 300 444 [9] (GAP) 


<a4o> 


Non-static FP 


[0,1] 


A FP which is mounted on a moving vehicle 


<a44> 


Access Rights requests 
supported 


[0,1] 


The FP can toggle this bit to enable or disable on air 
subscription (see annex A) 


<a46> 


Connection handover supported 


[0,1] 


Shall be understood as referring to voice services 



12.3.2.1.2 Higher layer information in Extended FP broadcast (Qh = 4) 

No Extended higher layer capabilities bits are used by the present document. 



12.3.2.1.3 



Extended Higher Layer capabilities part 2 (Qh = 11) 



The Extended Higher Layer capabilities, part 2, Fixed Part Information field shall be used indicating the support of 
ULE part 1 (bit < a^g >) as well as other services and optional features that may be supported by the RFP. 

Table 64: Extended Higher Layer Capabilities part 2 interpretation by the PP 



BIT Number 


Attribute 


Value 


Note 


<a24> 


NG-DECT Wideband voice 
supported 


[0,1] 


See TS 102 527-1 [i.6] (see notes 1 and 2) 


<a29> 


NG-DECT extended 
wideband voice services 
supported 


[0,1] 


Support or not support of TS 102 527-3 [13] (see 
notes 1 and 2) 


<a39> 


Support for ULE part 1 


1 


The present document. 


< a42 > 


Support of 'Re-keying' and 
'early encryption' 


[0,1] 


Support (or not support) of the 'Re-keying' and 
'default cipher key mechanism early encryption' 
procedures (related to feature [ULE1-N.17]) 


<a43> 


DSAA2 supported 


[0,1] 


Support (or not support) of the DSAA2 
(see EN 300 175-7 [71). 


< a44 > 


DSC2 supported 


[0,1] 


Support (or not support) of the DSC2 
(see EN 300 175-7 [7] and note 3). 


NOTE 1 : Value refers to the value to be set by FPs complying with the present document. PPs may need to 
understand other values due to the compatibility with GAP and NG-DECT Part 1 FPs. 

NOTE 2: All equipment compliant with the present document shall broadcast and shall understand the "Extended 
Higher layer capabilities (part 2)". 

NOTE 3: The support of the DECT Standard Cipher #2 (DSC2) requires the support of the DECT Standard 
Authentication Algorithm #2 (DSAA2). 
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13 Services and Interworking procedures 

13.1 Interworking specific procedures 

The different types of Interworking options supported by the present document are listed and described in annex B 
(normative). The U-plane and C-plane procedures that are specific for each Interworking type are defined in the 
applicable clause of annex B. 

13.2 Other Interworking procedures 
13.2.1 Transport of IWU-to-IWU data 

This procedure may be used to transport data between ULE applications peer-to-peer (i.e. FP to PP) in both directions. 

13.2.1.1 General requirements 

The transport of data shall take place over a ULE Service Call. The ULE Service Call Setup procedure shall be used to 
establish the call (see clause 12.2.1). At the end of the data transport the PP shall release the ULE Service Call 
procedure (see clause 8.7 of EN 300 444 [9]). 

13.2.1.2 Prerequisites 

A ULE Service Call shall exist prior to attempting to transport data using this procedure. 



13.2.1.3 



Procedure 



Data shall be sent using an «IWU-to-IWU» Information Element contained within an IWU-INFO call control 
message. The general format of the «IWU-to-IWU» message is shown in clause A. 3. 

The actual payload data for this message is defined on a ULE Application Protocol specific basis, and is not defined in 
the present document. 

Table 65: Values used within the «IWU-to-IWU» information element 



Information element 


Field within the information 
element 


Standard values 
within the field/IE 


Normative action/comment 


«IWU-to-IWU» 


<Length of content> 


L 


Length of content 


<S/R bit> 


1 


Transmission of message 


<Protocol Discriminator> 


05H 


ULE Configuration and Control 


IWU-TO-IWU INFORMATION 




Payload data format is protocol 
specific, and is not defined in the 
current document. 
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Annex A (normative): 

Parameters and Information Elements 

This annex describes: 

• the operating parameters used in the present document; and 

• the coding of profile specific Information Elements. 



A.1 Constants, variables and operating parameters 
A. 1.1 Operating parameters 

The following parameters are used in the present document. 

A.I .1 .1 Channel selection algorithms 

b (a parameter of the channel selection algorithm M2): 6 

m (delay between frame carrying the M^ channel selection information and the access frame): 2 frames 



A.I. 1.2 MAC layer 



Several MAC layer parameters are negotiable by means of MAC or NWK messages. Their default values are provided 
in clauses 12.1.3.8 and 12.1.3.5. 



A.I. 1.3 DLC layer 

Maximum SDU size with mandatory support at FP side: 500 octets 



NOTE: Other DLC parameters are negotiable by means of NWK messages. Their default values are provided in 

clauses 12.1.3.5. 



A.2 Coding of Information Elements 

The ULE specific coding of the following Information Elements are defined in the present document: 

• « ULE-MAC-CONFIGURATION-INFO » 

• « IWU-ATTRIBUTES » 
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A.2.1 Coding of the Information Element « ULE-MAC- 
CONFIGURATION-INFO » 

The purpose of the « ULE-MAC-CONFIGURATION-INFO » element is to define the usage of the selectable parts 
of the subfields sent on the ULE dummy bearer. This assigns one or more broadcast/paging channels and/or paging 
identity to a ULE PT. The layout is shown below. 



Bit: 


8 


7 


6 


5 


4 


3 


2 


1 


Octet: 
























« ULE-MAC-CONFIGURATION-INFO » 


1 




Length of Contents (L) 


2 




1 


Coding standard 


Control 


3 




1*" Channel Descriptor Type 


Channel Active Mask 


4 





spare 


Channel Periodicity 


5 





spare 


Start MFN4 


6 




Start MFN | Start FONT 


7 




con 


Bit Offset / Reserved 


8 
















Last Channel Descriptor Type 


Channel Active Mask 


k 





spare 


Channel Periodicity 


k+1 





spare 


Start MFN4 


k+2 




Start MFN | Start FONT 


k+3 




1 


Bit Offset / Reserved 


k+4 



Figure A.I: «ULE-MAC-CONFIGURATION-INFO» information element coding 

Reserved bit (octet 3): 

Bits 8 Meaning 

1 shall be set to '1' 

The value '0' is reserved for further expansion and shall not be used 



Coding standard (octet 3): 

Bits 7 6 Meaning 

DECT ULE TS 102 939 part 1, the present document 

All other values are reserved 



Control (octet 3): 

Bits 5 4 3 21 

00000 
00001 
All other values are reserved. 



Meaning 

Replace all descriptors 
Appends new descriptors. 



NOTE 1 : If any change to a PT's existing broadcast/paging channel descriptions is required, the existing channel 

descriptions may be removed and replaced by new ones by using a "Replace all descriptors" command. If 
only adding additional channels is required, the control command "Append new descriptors" may be 
used. 

NOTE 2: Code 'OOOOO'B "Replacing all descriptors" may also be used to clear all descriptors by not including any 
new descriptor in the IE. 
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NOTE 3: Code 'OOOOO'B may also be used when the insertion of descriptors is meaningless. 
Channel Descriptor Type (octet 4, k): 

Bits 8 7 6 5 Meaning 

1 Allocation of channel used for application broadcast, octet 4d, 5d..kd contains zeroes 

10 Allocation of channel used for paging, octet 4d, 5d..kd contains BitOffset. 

All other values are reserved. 

Each broadcast/paging channel description shall be a distinct type, it shall not be allowed to define a channel as 
broadcast and paging within the same channel description. If a single channel that is intended for both paging and 
broadcast is required, two channel descriptions shall be issued with the same Channel Periodicity, Start MFN4, Start 
MFN and Start FCNT but with different Channel Descriptor Types. 

Channel Active Mask (octet 4, k): 

Bits 4 3 21 Meaning 

i i i i Message activity (paging or application broadcast) may be indicated by bits in the Channel Active 

subfield (CA) of a message transmitted on a ULE dummy bearer. The Channel Active Mask in this 
IE qualifies which bits to inspect. This value (iiii) is used purely as a bit mask. 

Channel Periodicity (octet 5, k+1): 

Bits 4 3 21 Meaning 

n n n n Defines the number of frames between messages sent on this channel, calculated as a power of 2. 

The value (nnnn) is coded with the natural binary value and has the range from 0000 to 1111. So 
the range of the number of frames between messages sent on this channel is from 2'^0 to 2'^15, or 
in decimal from 1 to 32768, in steps of powers of 2. 

Start MFN4 (octet 6, k+2): 

Bits 7654321 Meaning 

p p p p p p p Defines the value of bits 4 to 10 of the multi-frame number in which this channel starts. This value 
(ppppppp) is coded with the natural binary value and has the range from 0000000 to 1111111, or 
in decimal from to 127. 

Start MFN (octet 7, k+3): 

Bits 8 7 6 5 Meaning 

q q q q Defines the value of bits to 3 of the multi-frame number in which this channel starts. This value 

(qqqq) is coded with the natural binary value and has the range from 0000 to 1 1 1 1, or in decimal 
fromO to 15. 



Start FCNT (octet 7, kH-3): 

Bits 4 3 21 Meaning 

t t t t Defines the frame number in which this channel starts. This value (tttt) is coded with the natural 

binary value and has the range from 0000 to 1 1 1 1, or in decimal from to 15. 

continuation bit (con) (octet 8, k-i-4): 

Bits 8 Meaning 

a further descriptor follows (starting in octet 9 or kH-5) 

1 this is the last descriptor 
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Bit Offset (octet 8, k+4): 



Bits 7 6 5 4 3 21 

V V V V V V V 



Meaning 

When Channel Descriptor Type is set to 0010 this value (vvvvvvv) indicates the bit position of the 
paging identity (BitOffset), this value is coded with the natural binary value and then has the range 
from 0000000 to 10101 1 1 (or to 87 in decimal). When Channel Descriptor Type is set to 0001 it 
is reserved and set to the fixed binary value 0000000. 
All other values are reserved. 



Multiple broadcast channels can be allocated for paging and/or application broadcast. 

A.2.2 Coding of the Information Element «IWU-ATTRIBUTES» 

The « IWU-ATTRIBUTES» Information Element may be used during the execution of the CC Service Change 
procedure in order to negotiate various attributes relating to the IWU. 

The base standard EN 300 175-5 [5] defines the basic structure of the IE, and the present document describes the 
profile-specific structure. 



Bit: 


8 


7 


6 


5 


4 


3 


2 


1 


Octet: 



























« IWU-ATTRIBUTES » 


1 




Length of Contents (L) 


2 




1 


1 1 1 Profile 


3 




1 


Negotiation indicator Profile subtype 


4 




1 


IWU function at FP 


5 







Maximum IVITU/SDU size PT => FT (most significant 7 bits) 


6 




0/1 


IVIaximum IVITU/SDU size PT => FT (least significant 7 bits) 


6a 







IVIaximum MTU/SDU size FT => PT (most significant 7 bits) 


6b 




1 


Maximum MTU/SDU size FT => PT (least significant 7 bits) 


6c 















ULE Application Protocol Identifier 


7 




0/1 


ULE Application Protocol Version 


7a 







EMC or extended Application Protocol Identifier 


7b 







EMC or extended Application Protocol Identifier (continued) 


7c 




1 


EMC or extended Application Protocol Identifier (continued) 


7d 















ULE Application Protocol Identifier 


k 




0/1 


ULE Application Protocol Version 


ka 







EMC or extended Application Protocol Identifier 


kb 







EMC or extended Application Protocol Identifier (continued) 


kc 




1 


EMC or extended Application Protocol Identifier (continued) 


kd 



Figure A.2: ULE specific «IWU-ATTRIBUTES» information element coding 
Coding Standard (octet 3): 



Bits 7 6 

01 

Profile (octet 3): 

Bits 5 4 3 2 1 

10000 



Meaning 

Profile Defined Coding 



Meaning 

ULE profile 
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Negotiation indicator (octet 4): 



Bits 7 6 5 Meaning 

Negotiation not possible 

10 Exchanged parameter negotiation 

10 Peer attribute negotiation 

110 Exchanged attribute negotiation and Peer attribute negotiation 

All other values reserved. 

Profile subtype (octet 4): 

Bits 4 3 21 Meaning 

ULE Part 1 transparent Interworking 

All other values reserved. 

IWU functionality at FP (octet 5): 

Bits 6 5 4 3 21 Meaning 

undefined 

1 Transparent routing 

All other values reserved. 

Maximum MTU/SDU size PT => FT (or bidirectional) (octets 6 and 6a): 

This 14-bit word represents the natural binary coding of the maximum MTU/SDU length, in units of four bytes (32 bits) 
to be used in PT => FT direction. The sending side shall not send MTU/SDU bigger than this value. The least 
significant bit shall be in position 1 of octet 6. 

Maximum MTU/SDU size FT => PT (octets 6b and 6c, optional): 

This 14-bit word represents the natural binary coding of the maximum MTU/SDU length, in units of four bytes (32 bits) 
to be used in FT => PT direction. The sending side shall not send MTU/SDU bigger than this value. The least 
significant bit shall be in position 1 of octet 6b. 

If octets 6b and 6c are not present, the MTU/SDU size value defined for PT => FT direction shall be also used if FT => 
PT direction. 

NOTE 1 : In the Interworking type "transparent interworking" the size of the SDU is equal to the size of the external 
MTU. 

ULE Application Protocol Identifier (octet 7, k): 

Bits 7654321 Meaning 

undefined protocol 

1 ULE Functional application protocol #1 

1 X X X X X X Proprietary ULE protocols 
All other values reserved. 

NOTE 2: When the coding for Proprietary ULE protocols is used, the bits 1 to 6 may be freely coded by the vendor 
to specify different proprietary protocols or any other use. The FP and PP may also use proprietary 
messaging to negotiate the protocol used. 
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ULE Application Protocol Version (octet 7a, ka): 

Bits 1-7 form a version number which may be used to further identify the ULE Application Protocol. A value of shall 
be used when there is no specific requirement to specify the version. 

EMC or extended Application Protocol Identifier (octet 7b-7d, kb-kd, optional): 

If bit 7 of the Application Protocol Identifier is set to '1' (proprietary application protocol) these three octets are used to 
code the EMC field that may be used to discriminate between different proprietary protocols. The EMC is a 16 bit 
number, which is inserted into the 'EMC field' as follows: 

Octet 7b, kb : 7 most significant bits of EMC (LSB inserted into bit 1 of 7b,kb) 
Octet 7c, kc : next 7 most significant bits of EMC (LSB inserted into bit 1 of 7c,kc) 
Octet 7d, kd : least significant 2 bits (LSB inserted into bit 1 of 7d,kd) 

NOTE 3: The use of standard IE coding rules allow the octet group 7, k to be ended at the end of 7a, ka. This means 
that the addition of the EMC is optional in the IE, and may be omitted, if not required by the specified 
ULE Application Protocol. 

If bit 7 of the Application Protocol Identifier is set to '0' the three octets 7b, 7c and 7d (or kb, kc, kd) are used to extend 
the Application Protocol Identifier, that has now 4 octets with a total of 4 x 7 bits. Most significant 7 bits are coded in 
octet 7 (or k) and LSB in octet 7d (or kd). 

NOTE 4: A total of 20 bits are usable since bit 1 of octet 7 (or k) has to be set to '0'. 

A.2.3 Coding of the Information Element «IWU-to-IWU» 

The «IWU-to-IWU» Information Element may be used to transport data between ULE applications peer-to-peer (i.e. 
FP to PP) in both directions. 

The base standard EN 300 175-5 [5] defines the basic structure of the IE. The actual payload data for the <IWU-to-IWU 
INF0RMAT10N> is ULE Application Protocol specific, and is not defined in the present document. 



Bit: 


8 


7 


6 


5 


4 


3 


2 


1 


Octet: 



























« IWU-TO-IWU » 


1 




Length of Contents (L) 


2 




1 


S/R 


Protocol Discriminator 


3 






4 




IWU-TO-IWU INFORMATION 








L+2 



Figure A.3: IWU-TO-IWU information element 

A.2.3. 1 IWU-to-IWU information field (octets 4 to L-h2) for Protocol 
Discriminator value "ULE Configuration and Control" 



Bit: 


8 


7 


6 


5 


4 


3 


2 


1 


Octet: 
























1 


Discriminator type 


4 






5 




Discriminator Specific Contents 








L+2 



Figure A.4: IWU-to-IWU information field (octets 4 to L+2) for Protocol Discriminator value "ULE 

Configuration and Control" 
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Discriminator type (octet 4): 

Bits 7654321 Meaning 

000 000 reserved 

1 reserved 

1 X X X X X X Proprietary ULE protocols 
All other values reserved. 

NOTE 1: The code 'OOOOOOO'B is reserved for ULE Common Control Protocol. 
NOTE 2: The code 'OOOOOOl'B is reserved for ULE Functional Application Protocol #1. 

A.2.3.2 Discriminator Specific Contents (octets 5 to L+2) for Discriminator 
type "Proprietary ULE protocols " 



Bit: 


8 


7 


6 


5 


4 


3 


2 


1 


Octet: 
























Proprietary Discriminator 


5 




Proprietary Discriminator (continued) 


6 






7 




ULE Proprietary contents 








L+2 



Figure A.5: Discriminator Specific Contents (octets 5 to L+2) for Discriminator type "Proprietary ULE 

protocols" 

The Proprietary discriminator consists of 2 octets (octets 5 and 6) and contains the EMC, with the most significant byte 
in octet 5 and the least significant byte in octet 6. 
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Annex B (normative): 

U-plane services and interworking procedures 



B.1 Scope of this annex 



This annex defines the Interworking conventions for different Interworking options supported by the present document. 
Currently only the transparent U-plane interworking (service [ULEl-I.l]) is supported. This interworking service may 
be used for the transport of several application protocols: 



B.2 Transparent U-plane Interworking 
B.2.1 U-plane procedures 

The external protocol packet or datagram shall be mapped into a DLC LU13 or LU14 SDU. 

The maximum value of the size of the external packet, and therefore the SDU, may be configured by means of C-plane 
procedures (see clause B.2. 2). 

The default value for the maximum SDU size is defined in clause 12.1.3.5 of the present document. 

Additionally, the following requirements apply regarding the maximum SDU size that shall be supported: 

FT requirement: 

• Receive direction: FT shall support at least a Maximum SDU size of 500 octets. By negotiation with the PT, it 
is possible to support higher or lower values than 500 octets. 

• Transmit direction: there is no minimum requirement. The Maximum SDU size shall not exceed the 
Maximum SDU size supported by the PT in receive direction. This is a result of the negotiation with the PT. 

PT requirement: 

• Receive direction: PT shall support at least a Maximum SDU size of 32 octets. By negotiation with the FT, it 
is possible to support higher values than 32 octets. 

• Transmit direction: there is no minimum requirement. The Maximum SDU size shall not exceed the 
Maximum SDU size supported by the FT in receive direction. This is a result of the negotiation with the FT. 



B.2. 2 C-plane procedures 



The parameters of the transported protocol may be configured by means of NWK layer procedures. The NWK layer 
information element « I WU- ATTRIBUTES » provides the transport of the required parameters. 

Multiple application protocols may be transported over ULE transparent Interworking. The negotiation of the 
transported protocol may be done by means of the CC Service Change procedure including the « IWU- ATTRIBUTES 
» Information Element. This procedure also allows configuring the maximum MTU size used by each application 
protocol. The highest value of maximum MTU size shall also be used as maximum SDU size for the DLC layer. 

See clause A.2.2 for the composition of the « IWU-ATTRIBUTES » IE used with the transparent U-plane 
Interworking. 
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Annex C (informative): 
Guidelines and examples 

This annex provides some guidelines and examples for implementation of the present document. 

C.1 Channel selection algorithms 

C.1 .1 Example of Implementation of Process MO 

The following text describes a possible implementation of the algorithm for process MO. 

C.1 .1 .1 Technical principles and objectives 

The algorithm is based on an adaptive variable RSSI threshold level (the RFP threshold level) used to evaluate if a 
channel is free for use. 

The objective of the proposed architecture is to balance the goal of pre-selecting the less interfered available channels 
with the need of offering multiple options for the process Ml in order to reduce the probability of collision. 

C.1 .1 .2 Possible implementation 

The different RSSI levels that the RFP may measure for a given channel are classified in "bins" separated 6 dB, in a 
similar way to the standard DECT channel selection algorithm. 

An adaptive variable threshold level is used to evaluate if a channel is free for use and announcement in the next 
broadcast opportunity related to the channel frequency. Channels with RSSI below the threshold will be announced as 
usable and channels above such level will not. 

The adaptive variable RSSI threshold level may be as low as the background noise level, if at such level the RFP may 
find an "enough" number of candidate channels. The value of what is "enough" is part of the design and, in this 
example, is defined by a table (see table C.1, column 3). 

If this is not the case, the RFP, will progressively raise the RFP threshold level in order to increase the chance of getting 
a sufficient number of candidate channels (for the next frame). 

The raise of the RFP threshold level will be progressive. It is proposed a rate of one bin step (6 dB) per frame. However 
slower rates may also be investigated. 

If more channels than the "enough" target are found, the RFP will (for next frame) progressively decrease the RSSI 
threshold value, until the value matches the "enough" target. Reduction in the threshold value will also be done at the 
same rate as the rise. 

If the number of channels that passes the RSSI criteria matches exactly the target, the threshold level will remain 
unchanged. 

In any case, the real number of channels matching the threshold evaluation will be announced in the M^ broadcast 
(irrespective of if it is lower of higher than the target for the threshold bin. 

The number of "target" channels varies for each bin. It is higher for low interference levels and is reduced when the 
RFP is forced to increase the threshold level due to higher interference. By doing that, the algorithm is accepting higher 
collision probabilities (due to the reduction in the offer) in turn of lower interference levels. Thus, it is implementing the 
first goal given in EN 300 175-3 [3] guidelines. 

For each threshold level, the algorithm defines also the PP threshold value. This is the value that should be transmitted 
in the info 1 field of channel M^. In the proposed sketch, the value of the PP threshold is calculated as a function of the 
FP threshold level adding a margin of some dB. The value of the margin decreases with the threshold level. For 
specification purposes, the resulting value is also tabulated in the table. 
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A possible design for the algorithm is given in table C.l. 



Table C.I : A possible design of the algorithm MO in tabulated format 



"bin" nr. 


RFP threshold RSSI level (dBm) 


Target number of offered 
channels (see note 1) 


PP threshold (dBm) (to be 
transmitted to the PPs) 




(see note 2) 






10 


-33 dBm 


1 


-33dBm(+0dB) 


9 


-39 dBm 


2 


-39dBm(+0dB) 


8 


-45 dBm 


2 


-45dBm(+0dB) 


7 


-51 dBm 


3 


-45 dBm (+6 dB) 


6 


-57 dBm 


3 


-51 dBm (+6dB) 


5 


-63 dBm 


3 


-57 dBm (+6 dB) 


4 


-69 dBm 


4 


-57 dBm (-Hl2dB) 


3 


-75 dBm 


4 


-63 dBm [+12 6B) 


2 


-81 dBm 


4 


-69 dBm {+12 6B) 


1 


-87 dBm 


4 


-69 dBm (-HlSdB) 





-93 dBm 


4 


-69 dBm (-H24 dB) 


NOTE 1 : The target number of channels refers to the available channels (channels that match the threshold 
criteria) within the 12 channels possible in each Mj announcement. 

NOTE 2: This design sketch does not enter to evaluate the convenience of operation above -33 dBm. 



C.1 .1 .3 Alternative implementation 

An alternative implementation that provides smother transitions in the threshold RSSI level in turn of a more complex 
implementation is given in table C.2. The design is identical to previous example; however the number of available 
channels used to decide if the threshold level should be moved up or down is based on the total pool of DECT channels 
(120 channels assuming 10 frequencies). 

For the preparation of each M^ announcement, the RFP computes the channels that should be in the announcement (by 

comparing the 12 channels in the future scan sequence with the threshold level), but also compares the whole pool of 
channels (120) with the threshold to see if the threshold itself should be raised of reduced. 

The result is a more stable threshold level. For instance, if the overall number of channels that would pass the threshold 
is i.e. 36, the threshold will remain at -69 dBm, even if in a given frame there are no channels passing the criteria. 

Table C.2: Alternative design of the algorithm MO in tabulated format 



"bin" nr. 


RFP threshold RSSI level (dBm) 


Target number of offered 
channels (see note 1) 


PP threshold (dBm) (to be 
transmitted to the PPs) 




(see note 2) 






10 


-33 dBm 


10 


-33dBm(+0dB) 


9 


-39 dBm 


15 


-39dBm(+0dB) 


8 


-45 dBm 


20 


-45dBm(+0dB) 


7 


-51 dBm 


25 


-45 dBm (+6 dB) 


6 


-57 dBm 


30 


-51 dBm (+6dB) 


5 


-63 dBm 


34 


-57 dBm (+6 dB) 


4 


-69 dBm 


36 


-57 dBm (-Hl2dB) 


3 


-75 dBm 


38 


-63 dBm (-Hl2dB) 


2 


-81 dBm 


40 


-69 dBm {+12 6B) 


1 


-87 dBm 


41 


-69 dBm (-HlSdB) 





-93 dBm 


42 


-69 dBm {+24 6B) 


NOTE 1 : The target number of channels refers to the available channels (channels that match the threshold 

criteria) within the whole pool of DECT channels assuming 10 frequencies (120 channels). 
NOTE 2: This design sketch does not enter to evaluate the convenience of operation above -33 dBm. 
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C.2 ULE Paging Mechanism 

C.2.1 Examples of ULE Paging IVIechanism 

This annex gives details of how the flexible ULE paging channel (channel B^) mechanism can be used to set up simple 
scenarios. 

C.2.1. 1 Example 1 

Only one channel defined giving access to up to 88 devices in every frame. Each PT is given the parameters shown in 
table C.3 as the parameters of a « ULE-M AC-CONFIGURATION-INFO » information element, then in every frame 
the Bjj channel data transmitted in the ULE dummy P^ channel is described in table C.4, this is arbitrarily given the 
channel designation 0100b for the Channel Active field, the two SubField Use fields (SFa and SFb) indicate paging 
information only. Because the channel is paging information the bit set in BitOffset determines which PT responds. 

Table C.3: Example 1; Single Paging Channel Descriptor Parameters 



Value 


Value 


DescriptorType 


2 


Start MFN 





Start FCNT 





ChannelPeriodiclty 


2'^0 


ChannelActive 


0100 


BitOffset 


0-87 



Table C.4: Example 1 ; First Channel ULE Dummy By Channel Values 



Sub Field 


Value 


CA (ChannelActive) 


0100 


SFa 


01 


SFb 


01 


BitOffset 


0-87 



C.2.1. 2 Example 2 

Three channels defined, 2 for paging only and one for broadcast only. Each PT is given the set of parameters from 
some/none/all of the following tables of parameters of « ULE-MAC-CONFIGURATION-INFO » information 
elements (see tables C.5, C.7 and C.9) depending on which channels that particular PT needs to receive. If the PT is not 
given any, it will not receive any paging message and will not receive the broadcast data. 

Table C.5: Example 2; First Paging Channel Descriptor Parameters 



Value 


Range 


DescriptorType 


2 


Start MFN 





Start FCNT 





ChannelPeriodiclty 


2A1 


ChannelActive 


0001 


BitOffset 


0-87 
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Table C.6: Example 2; First Paging Channel ULE Dummy By Channel Values 



Sub Field 


Value 


CA (ChannelActive) 


1011 


SFa 


01 


SFb 


01 


BitOffset 


0-87 



So this gives paging access to 88 identities once every 2 frames. 

Table C.7: Example 2; Second Paging Channel Descriptor Parameters 



Value 


Range 


DescrlptorType 


2 


Start MFN 





Start FCNT 


1 


ChannelPeriodicity 


2A2 


ChannelActive 


1000 


BitOffset 


0-87 



Table C.8: Example 2; Second Paging Channel ULE Dummy By Channel Values 



Sub Field 


Value 


CA (ChannelActive) 


1011 


SFa 


01 


SFb 


01 


BitOffset 


0-87 



So this gives paging access to 88 identities once every (2'^2) or 4 frames. 

Table C.9: Example 2; First Broadcast Channel Descriptor Parameters 



Value 


Range 


DescrlptorType 


1 


Start MFN 





Start FCNT 


3 


ChannelPeriodicity 


2'^3 


ChannelActive 


0010 


BitOffset 


Fields contain 
broadcast info 



Table CIO: Example 2; First Broadcast Channel ULE Dummy By Channel Values 



Sub Field 


Value 


CA (ChannelActive) 


1011 


SFa 


10 


SFb 


10 


BitOffset 


Fields contain 
broadcast info 



So this broadcasts 88 bits of broadcast data to all PTs selected to receive this channel, the 88 bit broadcast messages are 
sent 8 frames apart. This scheme gives the ULE dummy bearer sub field usage as shown in table C. 11. 
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Table C.11: Example 2; ULE Dummy By Channel Usage 



Multi-frame 


FCNT 





1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


First Paging 
Channel (Fast 
Page) 


X 




X 




X 




X 




X 




X 




X 




X 




Second Paging 
Channel (Slow 
Page) 




Y 








Y 








Y 








Y 






First Broadcast 

Channel 

(Broadcast) 








Z 
















z 










IVIulti-frame 1 


FCNT 





1 


2 


3 


4 


5 


6 


7 


8 


9 


10 


11 


12 


13 


14 


15 


Channel (Fast 
Page) 


X 




X 




X 




X 




X 




X 




X 




X 




Channel 1 
(Slow Page) 




Y 








Y 








Y 








Y 






Channel 2 
(Broadcast) 








Z 
















z 











NOTE: The CA Channel Active field shown in each By channel table has the value 'lOll'B. This indicates that 
these three channels are actively sending broadcast/paging data so any device that has been informed it 
should receive these channels knows there is data to check so it will ensure it receives the messages in the 
next frame in which they are sent. 
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